views:

75

answers:

3

So I have a layered ASP.NET MVC proof-of-concept application with good separation between presentation concerns, business logic, and infrastructure concerns. Right now it is operating off of a fake repository (i.e. LINQ queries against static IQueryable objects). I would like to create a functional SQL repository now.

That said, I don't want to simply tie it into a database that has a 1-1 mapping between tables and entities. That wouldn't meet the business need I am hoping to solve (partial integration with existing database - no hope for convention over configuration).

Do you have suggestions for which ORM / mapping tools I should consider and/or avoid?
Do you have suggestions for articles/books I could look at to help me approach this topic?

Would it be better to simply use parameterized queries in this scenario?

+4  A: 

NHibernate sounds like a good fit for what you are looking for. You will be able to make your repositories call queries in either HQL or using the API, either way you can get to your database and shape the data to fit the way your repository is being used. It will always be hard to make a square peg fit into a round hole though. SO has lots of nice support when you get into using NHibernate, good luck.

Mark Dickinson
To add to this, using NHibernate gives you a good way of working in a partial integration with your old database, as it can build a schema to varying degress as required. This behaviour is also nice when unit testing against SQLite for instance.
Mark Dickinson
Furthermore, the mapping can be expressed in xml that is not as verbose as some other ORMs. This is very helpful when you need to make a change or encounter a new use case, especially where polymorphism is concerned.
Mark Dickinson
NHibernate also has a fluent configuration addin which is quite helpful when refactoring. Maintaining manual mappings can be tiresome if the schema contains many tables. NHibernate also supports automappings and convention based appproach.
Nilesh Gule
+7  A: 

Entity Framework in version 4 would definitely allow you to:

  • have a mapping between the physical database schema and your conceptual schema, e.g. having an entity mapped to several tables, or several tables joined together forming a single business entity

  • grab data from views (instead of tables directly)

  • use stored procedures (where needed and appropriate) for INSERT, UPDATE, DELETE on every entity

marc_s
As jfar implied, no one answer can be correct. However, I'm choosing this as I hadn't seriuosly considered EF4 and upon researching it further it looks like it is a viable option.
Mayo
+1  A: 

As you mentioned in the question, it is very debatable to choose an ORM. Different people will have different project needs. I am not exactly sure what will take priority for you. Here is what I have tried myself.

NHibernate seems to be the most commonly used ORM in DotNet projects. I feel it suffers from a typical open source problem. It offers so many features but the documentation really sucks. If you have lots of time at your disposal you can give it a shot.

Another options is to go for something like Entity Framework. Its very easy to set up and get up and running. With version 4.0 and the CTP there is provison for code first as well as fluent mapping and configuration. Since you have said you would want to keep the domain model separated EF 4 will help you because it has a notion of conceptual model which is an abstraction over the mapping layer.

You can refer to few links below for the blogs I had written based on my experience http://nileshgule.blogspot.com/2010/08/entity-framework-hello-world.html http://nileshgule.blogspot.com/2010/09/nhibernate-code-first-approach-with.html http://nileshgule.blogspot.com/2010/09/entity-framework-first-query-using.html http://nileshgule.blogspot.com/2010/09/entity-framework-learning-series.html

Nilesh Gule
I think it's ironic that you think EF4 Code First, primarily documented in blog posts, has better documentation than NHibernate, which is also documented in blog posts. I'd honestly like to believe that EF4 has better documentation since Microsoft has the resources to do so, but that hasn't been my personal experience to date.
Michael Maddox
I agree with you Michael about the documentation of EF code first approach. But at the same time we need to realise that its a CTP and I am sure when the RTM version is out we'll definately have a much better documentation available. My personal experience with NHibernate has been bit disappointing. Some if the live stuff had very little documentation available and I had to rely on other resources to get the getting started sample working in the first place.
Nilesh Gule