Home/ Questions/Q 975345
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-16T03:34:17+00:00

I didn’t use LINQ to SQL in project, I just went through a hand-on

  • 0

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!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0