CODEWITHSUNDEEP
c#asp.net-mvc-2data-access-layer
Paul
Paul

Reputation: 2759

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.

Upvotes: 2

Views: 2422

Answers (4)

Kevin Pang
Kevin Pang

Reputation: 41442

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

  1. NHibernate
  2. 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.

Upvotes: 3

Lester
Lester

Reputation: 4413

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.

Upvotes: 0

DaveDev
DaveDev

Reputation: 42175

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.

Upvotes: 0

Kelsey
Kelsey

Reputation: 47726

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.

MVC + Repository Pattern - Still depends on Data Model?

Upvotes: 0

Related Questions