LINQ实体作为业务对象-pro / cons

Question

the dbml file generated by Visual Studio (sqlmetal) comes with entities mapped to database tables. In your opinion, these clases are suitable to be used as domain model classes? Or should we avoid them and isolate them into the data access layer only?

Thanks

Answer 1

In most cases, the layer of sugary goodness between the entity objects and writing the SQL is your DAL. The entire purpose of LINQ is to allow much more expressive constructs with your DAL than has been possible in the past.

Without LINQ, in your BL you might be limited to method calls such as GetCustomersByLastName(string) against your DAL. The only reason you write that method is because somewhere in your BL, you need to get customers by last name. This means your DAL contracts are explicitly driven by the needs of the BL. Whereas with LINQ, you are freed from the concrete dependency between the needs of the BL and the contracts of the DAL. The DAL can be completely agnostic as to specific usage; it merely exposes the contracts of the entities and their relationships, and the BL uses them at-will without concern for their data implementation. That is true separation of concerns.

If you hide the power of LINQ behind a traditional DAL, what's the point of using LINQ at all?

Answer 2

For a simple enough application, the big plus of using the LINQ entities directly is - simplicity. You can avoid having Yet Another Layer in your code, you can avoid having to write a lot of boilerplate logic to map from your business object to your LINQ entities (although there are tools like AutoMapper which can help a lot here).

On the other hand, as you say - your database probably isn't a spitting image of your domain model. Then again, if you need this capability to map between a given physical database model and your logical domain model, maybe you should have a look at the Entity Framework instead? That's exactly the mainstay of EF - these two models and the mapping layer between them.

Marc

Answer 3

It Depends

If you're domain objects are very simple and your project small, then using those classes isn't a problem. It would be a waste of time to write an entire extra layer that just repeats those classes.

If the objects are complicated and don't map in a straitforward way, another layer is essential to separating those details from the data access layer.

If you really aren't sure, you can start off using them directly and then add in another layer once it is apparent that you will need it.

Answer 4

I think it depends on scenarios.

I am now writing a WCF service, my data model is not very complicated but all tables have foreign keys and relationships between tables make linq create a quite complex objects tree.

From the client point of view it doesnt make sense to retrieve all this objects tree, and also the return xml message would be quite heavy (so if I dont change the message size max allowed value I get errors).

In this case I had to create custom views on LINQ objects to return just data client is expecting to retrieve. This is quite a pain as I had to re-write most of entities but in the end I have full control of the communication with client.