ASP.NET - Data Access Guidance
Microsoft has published Data Access Guidance for ASP.NET 4.5. Most of the changes are related to new features in 4.5, such as those in Web Forms and the new ASP.NET Web API.
Some notes from the guidance -
- Use ORMs wherever possible with ASP.NET Web Forms and MVC, but ADO.NET directly (through the Database helper) in ASP.NET Web Pages
- For WebForms data controls
- For Displaying a Single Record - Use FormView to customize generated HTML; for maximum automation of HTML generation use DetailsView
- For Displaying Lists - Use ListView to customize generated HTML; Repeater for customized HTML but read-only access and better efficiency (but lesser advanced features); and GridView for maximum automation of HTML generation
- ASP.NET Web Forms data binding methods -
- Data Source Controls for simple binding without writing any code
- Model Binding when it is feasible to write data retrieval and update code
- Manual Data Binding when fine-grained control over binding needed or model binding not supported
- Data-Binding Expressions
- Eval and Bind for weakly typed data
- Bind and BindItem for strongly typed data
- Use colon in opening delimiter (<%#:) to enable automatic HTML-encoding
Notably, there is a guidance on how to choose between WCF Data Services and ASP.NET Web API for your web services -
Choose WCF Data Services if you want to quickly expose a database over HTTP for use inside a firewall on an internal company network.
Conversely, choose Web API for Internet-based services because the whitelist approach is more secure than the blacklist approach.
WCF uses a black-listing approach to security restrictions (by default everything is made available) whereas Web API uses a white-listing approach (by default nothing is made available)
There are a lot of walkthroughs for various scenarios covered on MSDN – you can refer it for more details.
ORMs wherever possible?
by
Jonathan Allen
Re: ORMs wherever possible?
by
Roopesh Shenoy
Depending on the feature set needed, you could either go for a full-fledged ORM such as EF/NHibernate or even pick a thinner mapper such as Dapper.NET. A lot of enterprise work is based on dealing with legacy databases, where a full-fledged ORM can bring in a lot of benefits.
Eventually, it's just a matter of profiling and seeing whether ORM causing the biggest performance hit, and whether the gain by writing your own data access is worth extra developer time in terms of development/maintenance. I haven't seen that yet in the projects that I have worked on.
that's not even taking into account the bad data access patterns that ORMs tend to lead to.
Isn't that the same argument that you can both cut vegetables or cut yourself with a knife?
The same considerations would apply to a lot of other libraries as well (Spring.NET anyone?). I guess you shouldn't use these as an excuse for knowledge deficit (for e.g. use ORMs so you don't have to learn SQL!) - no - you should know the underlyings well enough, its just that you are adding a layer of abstraction to make yourself more productive. And you should know when to dive down one layer on a case-by-case basis in case something doesn't work as it's expected to.
Re: ORMs wherever possible?
by
Mark N
Performance: Is good enough good enough? Many times it is. If not, then an ORM is not possible in that instance.
What about all the bad data access patterns that not using an ORM lead to?
Re: ORMs wherever possible?
by
Mark N
What Microsoft should add as the #1 guidance: If you don't know what you are doing or how to architect it right, get someone who does to help you.
That being said, anyone with good sense should take this guidance with a grain of salt.
Re: ORMs wherever possible?
by
Eben Roux
It seems as though Microsoft 'guidance' is aimed at managers.
Re: ORMs wherever possible?
by
Mark N
Your choices [typically] are:
Use an ORM
Write your own ORM type code
Write difficult to maintain code/apps.
Re: ORMs wherever possible?
by
Eben Roux
Educational Content
Tuning the Size of Your Thread Pool
Kirk Pepperdine May 23, 2013
Co-making Great Products
Jeff Patton May 22, 2013




Hello stranger!
You need to Register an InfoQ account or Login to post comments. But there's so much more behind being registered.Get the most out of the InfoQ experience.
Tell us what you think