LINQ Entities vs Custom Entities in LINQ to SQL

Question

I didn't use LINQ to SQL in project, I just went through a hand-on lab for Developing Data Access Logic with LINQ, one of the tasks is to create entity translator classes to translate between linq entities and business entities.

I am a little confused about this because I thought the reason we use LINQ to SQL is that it can auto generate LINQ entities for us, we can query/update/insert/delete the entities right away. It would be great if we don't have to define our own custom entities and bother about the mapping between our entities and LINQ entities. But since the lab define business entities, I know I am wrong.

Can someone tell me in which situation should we define business entities instead of using entites LINQ to SQL right away? What is the benifit of using LINQ to SQL against ADO.Net in this situation? I am looking forward for your answer, thanks a lot in advance!

Answer 1

You ask an excellent question, which is why many people (myself included), feel like building a layer of business objects on top of L2S (or other ORM) entities is a waste of time. If you need to complete those steps in order to finish the lab (for a school assignment or something similar), then do so, but I wouldn't recommend it for an actual environment.

Answer 2

LINQ entities exactly mach your database columns. If your business entities do so also, then that's fine, you can use the LINQ entities directly (which is what I usually do).

If you business rule require more complex business entity, you will need to map them to Linq entities.

Answer 3

Using the LINQ entities binds you to your data persistence. For many applications, this is no big deal. But for others, it's a very bad design.

For example, if your application exposes an external API for customers to consume, then you don't want to expose your persistence entities to your customers. Otherwise, if you ever need to change your data model (requirements change, tweaking for performance at a larger scale, etc.) then you'll also be changing your exposed API.

For many large and more complex projects, you want to keep a clear separation between business objects and data persistence. This is especially true if the programmers and DBAs are on different teams and do very different things. They should work together on designs, but programming logic and database persistence are different technologies with different advances and limitations. The mapping between them is how they'll communicate, but one should not be bound by the limitations of the other.

As others have said, for many smaller projects this isn't a big deal. If your application is just forms over data, and the data is relatively simple, and that direct relationship isn't going to change, then the LINQ classes are fine to use.

Answer 4

It depends on your data. I have worked with some crazy organicly evolved databases where there were lots of unused columns that were retained for historical lookup from other apps(damn you SOX compliance >=( ) and many other issues.

We created business object mappings to hide all those historical warts and present a clean appearance to other areas of the code.