NHibernate vs LINQ to SQL

by

LINQ to SQL forces you to use the table-per-class pattern. The benefits of using this pattern are that it’s quick and easy to implement and it takes very little effort to get your domain running based on an existing database structure. For simple applications, this is perfectly acceptable (and oftentimes even preferable), but for more complex applications devs will often suggest using a domain driven design pattern instead (which is what NHibernate facilitates).

The problem with the table-per-class pattern is that your database structure has a direct influence over your domain design. For instance, let’s say you have a Customers table with the following columns to hold a customer’s primary address information:

  • StreetAddress
  • City
  • State
  • Zip

Now, let’s say you want to add columns for the customer’s mailing address as well so you add in the following columns to the Customers table:

  • MailingStreetAddress
  • MailingCity
  • MailingState
  • MailingZip

Using LINQ to SQL, the Customer object in your domain would now have properties for each of these eight columns. But if you were following a domain driven design pattern, you would probably have created an Address class and had your Customer class hold two Address properties, one for the mailing address and one for their current address.

That’s a simple example, but it demonstrates how the table-per-class pattern can lead to a somewhat smelly domain. In the end, it’s up to you. Again, for simple apps that just need basic CRUD (create, read, update, delete) functionality, LINQ to SQL is ideal because of simplicity. But personally I like using NHibernate because it facilitates a cleaner domain.

Edit: @lomaxx – Yes, the example I used was simplistic and could have been optimized to work well with LINQ to SQL. I wanted to keep it as basic as possible to drive home the point. The point remains though that there are several scenarios where having your database structure determine your domain structure would be a bad idea, or at least lead to suboptimal OO design.

More Related Contents:

  1. LINQ-to-SQL vs stored procedures? [closed]
  2. Linq: adding conditions to the where clause conditionally
  3. LINQ Between Operator
  4. LINQ across multiple databases
  5. Learning about LINQ [closed]
  6. How can I reject all changes in a Linq to SQL’s DataContext?
  7. LINQ with SQLite (linqtosql)
  8. How to create a dynamic LINQ join extension method
  9. LINQ not updating on .SubmitChanges()
  10. How to dynamically add OR operator to WHERE clause in LINQ
  11. LINQ To SQL exception: Local sequence cannot be used in LINQ to SQL implementation of query operators except the Contains operator
  12. Linq To Sql – Dynamic OrderBy – Case When
  13. Is there a pattern using Linq to dynamically create a filter?
  14. Linq to SQL how to do “where [column] in (list of values)”
  15. Multiple WHERE clause in Linq
  16. How do I write this cross apply query in LINQ-to-SQL?
  17. Tradeoffs using NHibernate 3.0 QueryOver or LINQ provider
  18. Point connectionstring in dbml to app.config
  19. How to implement Unit of Work that works with EF and NHibernate
  20. Building Dynamic LINQ Queries based on Combobox Value
  21. C# LINQ find duplicates in List
  22. LINQ to SQL Left Outer Join
  23. LINQ – Left Join, Group By, and Count
  24. When should I dispose of a data context
  25. LINQ Partition List into Lists of 8 members [duplicate]
  26. Use LINQ to concatenate multiple rows into single row (CSV property)
  27. Get table-data from table-name in LINQ DataContext
  28. PowerShell equivalent of LINQ Any()?
  29. Linq To Entities – how to filter on child entities
  30. Simple Linq query has duplicated join against same table?

Leave a Comment