.NET news » Search results

SharePoint 2010 introduces a number of new ways to access business data and present it to the user. We’ll show you several options that range from no-code solutions to fully integrated Office add-ins.

The purpose of this article is demonstrate how to build a Windows Forms application that encrypts files through the use of the RijndaelManaged class, a symmetric algorithm, which is used to encrypt and decrypt data by using its automatically generated Key and IV. Encryption involves the creation of a cipher (an algorithm) that takes data and a generated key as its input. The algorithm will behave in accordance with the length of the key. A symmetric algorithm is one that uses the same key to both decrypt and encrypt the data file. In our case, we will use the RSACryptoServiceProvider, an asymmetric algorithm, to encrypt and decrypt the key to the data encrypted by RijndaelManaged…

OData lets you access data over the Web through simple HTTP commands. We’ll show you how the jQuery DataTables plug-in along with the Microsoft .NET Framework and Silverlight OData client libraries let you retrieve and display this data quickly, easily and with style.

The performance of data-driven Windows Phone 7 apps relies on both good UI coding practices and snappy access to data. We’ll cover some important design considerations for using Windows Azure effectively with Windows Phone apps.

Explore ways to reduce page load time, manage state efficiently, scale back on memory use, handle resources better, and improve data access in your ASP.NET applications.

Online Article: The Baker's Dozen: 13 Productivity Tips for ADO.NET 2.0

This installment of "The Baker's Dozen" presents a variety of tips and techniques to become productive with data handling techniques using ADO.NET 2.0 in Visual Studio 2005. ADO.NET 2.0 is faster than the first version of ADO.NET; in some instances, significantly faster. While many view ADO.NET 2.0 as more evolutionary than revolutionary, it provides many functions to give developers greater control over data access and data manipulation. It also leverages the new database capabilities in SQL Server 2005. In addition, ADO.NET 2.0 simplifies the creation of multiple-database solutions.

A WinForms UI using WCF services, Entity Framework, repository data access, repository caching, Unit of Work, Dependency Injection, and every other buzz work you can think of!

This new site editor for ASP.NET Web Pages is different from the usual Microsoft product. See how it simplifies everything from site creation to data access to deployment and even Search Engine Optimization.

I can’t say I’ve asked the framework guidelines folks about this but I’m fairly sure there would be a lot of agreement from the guidelines gurus; so in the spirit of approximately correct advice I give you Rico’s Guidelines for Performant Properties.

I should start by saying I wish more people just used fields instead of committing these terrible sins with their properties.  If we had the notion of a type-safe, read-only field the world would be a better place.  Alas…

So, you’re using a property, the most important thing to remember is that it will seem very much like a field in all ways.  It looks like a field and feels like a field, people will expect it to perform like a field.  So with that in mind:

Accessing the property should not allocate any memory; people are going to use this thing in loops walking over whatever data structure you are presenting, they expect that this data is sitting around and being accessed. Accessing the property should not “synchronize” – if there is any locking to be done it should be done at a higher level than a single field, by the time you’ve acquired whatever object has the property on it, it should already be safe to read it. Accessing the property should not do any I/O, especially not any network I/O, again see above, by the time you’re reading the property the object offering it should have done whatever I/O was needed. Accessing the property should not be an operation with complexity greater than O(1) – that means no loops.  At all.  You could haggle me as high as O(lg(N)) if we’re talking about an property that is an “indexer” but no higher. Accessing the property should not have side-effects (i.e. it's strictly a read operation, it changes nothing)

What you’re left with is you can use your object state and the argument (if an indexer) to do a constant-time lookup, or log-time at worst, in an already existing data structure and immediately return the result.  That’s it.

Why?

Pit of Success is the only reason you need.  In my opinion, patterns more complicated than the above are doomed to fail.  If you allow say network access, an RPC or the like, on each property fetch, then you promote things like field-at-a-time access to remote data.  Not only is this astonishing to users of the API it is incredibly inefficient.  If you follow the rules above you soon realize that you must allow some kind of query to get the data you need and then you can use properties all you like to access that data.  That is a much better pattern, it leads to success.

Remember that if you allow things like I/O or synchronization you can easily get property access times that are measured in milliseconds, this simply will not do.  A typical interactive scenario might have a budget of say 100ms for prompt response and it might require access to several dozen properties just to paint the screen properly.  This has several issues:

If property access is say 1 millisecond then accessing 10 properties (not at all crazy) would be 10% of your overall budget – that’s nuts! The interactive code must be able to use your properties with confidence, that means they cannot block and should not be subject to large variability, else you get UI that is non-responsive for extended periods of time

Frequent access to properties is very common and therefore must be astonishingly cheap if only to keep a handle on the Joules your program consumes – an increasingly important metric for modern platforms.

From a time perspective, I like to see properties that have access time measured in nanoseconds.  Let’s say 10^-8s.  I can reasonably see systems with tricky indexing that might go has high as 10^-7 or even 10^-6.  When your time is getting to be 10^-5 or larger, you really need to start thinking about your design.  That’s too much work to put inside a thing that looks like a field access.  Give your users a fighting chance to understand where their costs are and let them query for a batch of results, probably asynchronously and then access them quickly when they arrive.  That’s going to be a successful pattern.

It goes without saying that under these conditions, the flexibility to version/replace/subtype virtual-call properties is actually illusory.  If you were to try to do something new and costly, or even just very different in a subtype you would likely cause all manner of problems for callers.  So while you do get to change things a somewhat, you cannot and must not, use that flexibility to access new and different subsystems or the like inside of a method that is supposed to be as small as a getter.  You are necessarily very constrained.

When I consider all of this I arrive squarely at the conclusion that more fields and fewer properties would be better.  Don’t hide real work inside a property and don’t use them as a synchronization tool.  Once you decide that you need a fetch/read pattern you soon find that that reading thing can be very simple/fast indeed and that perhaps fields were just fine after all.

Something to think about anyway. 

Visual Studio 2005 offers new capabilities in many different areas, such as data access, language enhancements, IDE productivity features, deployment, Office integration, XML, and many others!