BT

ASP.NET - Data Access Guidance

by Roopesh Shenoy on Sep 20, 2012 |

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-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. 

Hello stranger!

You need to Register an InfoQ account or 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

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

ORMs wherever possible? by Jonathan Allen

ORMs wherever possible? Not if you care about performance. Even with the recent enchancements EF is still slower than straight ADO.NET, and that's not even taking into account the bad data access patterns that ORMs tend to lead to.

Re: ORMs wherever possible? by Roopesh Shenoy

ORMs cut out a lot of plumbing code (unless you are rolling your own thinner ORM).

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

Not all ORMs are created equal. EF seems to be equal to EJB 1/2. Too bad history is being repeated vs learned from.
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

Good comments Roopesh.

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

Agreed. I prefer not to use an ORM.

It seems as though Microsoft 'guidance' is aimed at managers.

Re: ORMs wherever possible? by Mark N

Really? Aimed at managers? It seems aimed at the mainstream .NET developer. Not saying the guidance is good, just saying where it is pointed. Using ORMs is not wrong. Using them improperly is.

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

Right. What I mean is that it seems to be there so that managers can say: "see, there is the guidance." :)

Re: ORMs wherever possible? by kattypier sharma

dapfor provide net grid and best tutorial for APP.NET. more detail you can visit on dapfor. com

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

8 Discuss

Educational Content

General Feedback
Bugs
Advertising
Editorial
InfoQ.com and all content copyright © 2006-2013 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT