Home/ Questions/Q 279673
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-12T05:03:09+00:00

Whenever I read an article on linq to entities, I sounds like I should

  • 0

Whenever I read an article on linq to entities, I sounds like I should embed my business logic in the generated entity-classes.

This would means that the “user” of the business-objects (controller, service-layer, …) would have to know about the datacontext-object that’s needed to use linq.

It would also mean that the DAL-logic and the business-logic will be mixed up.

A lot of microsoft examples use some kind of DTO-approach. I’m not a big fan of the DTO pattern.

So should I let the business-object encapsulate the linq-entity and provide access to it using properties, or should I stick with the DTO pattern?

What are your suggestions?

Thanks

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The entity model generates partial classes. In a project of mine I’m using an entity model inside a class library and added a few .cs files to it that add functionality to the default entity classes. (Mostly functions related to error and message logging to a database table and a method to import/export all data to XML.)

    But true business logic is located in a second class library that refers to this entity class library.

    Let’s explain. First I created an entity model from a database. It contains a list of company names and addresses. I do this by choosing “New project|Class library” and then add an ADO.NET Entity Data Model to this library. The Entity model will be linked to my SQL Server database, importing the tables I need and auto-creates classes for the tables I want to access.
    I then add a second .cs file for every table that I want to expand. This would be a few raw methods that are strongly linked to the database. (Mostly import/export methods and error logging.) This I will call Entity.Model, which will compile to Entity.Model.dll.

    Then I add a second project which will contain the business logic. Again, I use “New project|Class library” to create it and add Entity.Model.dll to it’s references. I then start writing classes which will translate the database-specific classes to more logical classes. In general, I would not have to make many changes except that I will protect or hide certain fields and add a few calculated fields. The business logic would only expose the functionality that I want to access from my client application and not a single method more. Thus, if I don’t allow the client to delete companies then the “Delete” function in the entity model will not be exposed in the business layer. And maybe I want to send a notification when a company changes their address, so I’ll add an event that gets triggered when the address field of the company is changed. (Which will write a message log or whatever.) I’ll call this business.logic and it compiles to Business.Logic.dll.

    Finally, I’ll create the client application and will add a reference to Business.Logic.dll. (But NOT to the entity model.) I can now start to write my application and access the database through the business layer. The business layer will do validations, trigger a few events and do whatever else in addition to modifying the database through the entity model. And the entity model just serves to keep the database relations simple, allowing me to “walk through” the data through all foreign links in the database.

    • 0