ASP.NET MVC2 Data Access Layer

views:

829

answers:

ASP.NET MVC2 Data Access Layer

For a small/medium sized project I'm trying to figure out what is the 'ideal' way to have a domain layer and data access layer. My opinions on coupling tend to be more towards the view that the domain models should not be tightly coupled with the database layer, in other words the data access layer shouldn't actually know anything about the domain objects.

I've been looking at Linq-to-sql and it wants to use its own models that it creates, and so it ends up VERY tightly coupled. Whilst I love the way you use linq-to-sql in code I really don't like the way it wants to make its own domain objects.

What are some alternatives that I should consider? I tried use NHibernate but I did not like the way I had to use to query and get different objects. I honestly love the syntax and way you use linq, I just don't want it to be so tightly coupled to domain objects.

I posted an answer to a similar question that might be of help. I could repeat it all here but I thought I would just point you to the answer there since I would suggest the same type of repository patten to decouple your data.

http://stackoverflow.com/questions/2717247/mvc-repository-pattern-still-depends-on-data-model/2717358#2717358

Kelsey 2010-04-30 22:42:40

This is a possible solution, but it negates all the nice features NHibernate does for you (e.g. 1st/2nd level caching, lazy-loading/eager-loading, etc.) while requiring you to write a lot of mapping code between the generated classes and your own (which admittedly can be simplified using something like AutoMapper). I'd say use NHibernate over this approach to avoid having to write so much plumbing code yourself.

Kevin Pang 2010-04-30 22:45:41

+1 A:

If you don't want your domain to be tightly coupled to your database, then your choices are pretty much:

NHibernate
Entity Framework

Linq 2 Sql as you've discovered generates code from your database layer, so that's out of the question. Same goes for Subsonic and LLBLGen Pro (I believe, correct me if I'm wrong). Entity Framework used to fall into this boat as well, but version 4 has shipped with "code first" support so it's definitely an option.

Both NHibernate and Entity Framework support LINQ queries, although Entity Framework's LINQ support is supposedly superior to that of NHibernate's. I agree that HQL and Criteria queries are not nearly as elegant as LINQ, but I have a feeling NHibernate's LINQ support will be vastly improved come version 3.0.

Kevin Pang 2010-04-30 22:43:12

Whats the performance differences between NHibernate and the Entity Framework? I know when I was using NHibernate for a while it had a pretty slow startup time, which I didn't particularly like. Is the entity framework similar in that respect?

Paul 2010-04-30 23:43:43

Instantiating an NHibernate SessionFactory is an expensive operation, but a negligible one for most apps since it only needs to be instantiated once per application. In an ASP.NET MVC 2 app, you will probably instantiate a SessionFactory on Application_Start and store it as a singleton. Every subsequent web request from any user from that point on would use the same SessionFactory instance which won't incur the same performance penalty. I have a blog post showing how to do this: http://www.kevinwilliampang.com/2010/04/06/setting-up-asp-net-mvc-with-fluent-nhibernate-and-structuremap/

Kevin Pang 2010-05-01 00:19:30

As for Entity Framework, I don't have a lot of experience using it. I've played around with it some and it didn't seem to have the same loadup issues as NHibernate. But, as I said in my previous comment, this loadup time is pretty much negligible for 99.9% of web apps since it'll only be incurred once per application lifetime.

Kevin Pang 2010-05-01 00:24:14

Ahh I didn't realize you could do that with NHibernate, in my little playing around with it I never really set anything like that up. Very interesting stuff. I may well have to consider going back to NHibernate now. I saw on your blog that you used Fluent NHibernate, other than not writing xml config files is there any differences between Fluent and vanilla NHibernate I need to concern myself about?

Paul 2010-05-01 00:34:23

Nope. Fluent NHibernate is pretty much feature complete and makes mapping much less tedious. If you ever need to go back to the XML format for a particular mapping, it supports that as well, so you shouldn't ever find yourself stuck in a corner.

Kevin Pang 2010-05-01 10:17:23

You can use LINQ to SQL to create types that represent data entities. These are pretty much just classes that represent the tables in your DB. In an MVC project, you should use these to supply data to a Business layer, from which you can start to define Business entities and then (and very importantly, in my opinion) define your Presentation Model.

DaveDev 2010-04-30 22:46:16

I know you don't really like NHibernate, but if you want to give it a second look, check out http://sharparchitecture.net/. They do a really great job in laying out a project template while properly separating concerns.

Lester 2010-04-30 22:48:53

ansaurus

tags:

views:

answers:

ASP.NET MVC2 Data Access Layer

related questions