As I began writing web applications with asp.net I started with small projects that used a Linq-To-SQL mapper for database access to a MSSQL Server.
After gaining some expierence I switched into a classic 3 tier with Graphic Layer, Business Layer, Data Layer. The only function of the Data Layer was to provide methods insert/update/delete without any logic and logic the form of selection methods.
Over the time I realized that it would be better not to provide the database classes up to the GUI (took some time unfortunately). I switched into using Business classes in the BL that are used for all operations performed by the BL and display by the GUI in the form of getting List from the BL.
A great advantage is that I can provide additional properties that are not represented by the database itself. However, I did that mapping inside the BL myself with methods that mapped the corresponding BL class to the database class.
I guess thats where O/R mapper come in handy? Until now I haven't realized their purpose, but I think I just found it. I've recently tried out using the new Entity Framework with .net framework 4, but I'm only using it like the Linq-To-SQL DataContext.
Is there a way to achieve the mapping automatically? If yes, is that something the new Entity Framework provides or do I need to look for a O/R Mapper like NHibernate?
I use NHibernate exclusively in my projects. I like the control and flexibility it gives me. There is a 'shortcut' called Active Record that uses NHibernate under the covers but provides a really nice an simple interface to NHibernate.
NHibernate has a steep learning curve, but when you get past that - it is really smooth sailing. When (and if) you venture the way of NHibernate, check out Ayende for cool tips.
(Entity Framework is an O/R Mapper.)
If you're serious about getting your hands dirty with ORM (but relatively new to that area), I highly recommend something like TekPub's videos on these topics. You'll be able to see these tools in use starting from scratch. It is a graceful introduction to some simple, but real-world issues like the ones you mention.
I've had a great time using Entity Framework 4.0 (+ the CTP). I think you'd have a much easier time dealing with an ORM like that. EF4 provides everything you need to interoperate with MSSQL from C#/.NET. You won't have to write a single line of SQL, and it has full support for LINQ (through ObjectQuery).
LinqToSql is an ORM, so you are already using one. Taking LinqToSql out and replacing it with EntityFramework or NHibernate won't solve the problems you appear to be having right now.
Here are some things you should learn more about to help give you additional context:
- AutoMapper
- Data Transfer Objects (DTOs)
- Plain Old CLR Object (POCO)
