Business Logic Layer Design

Question

I feel like such a noob for asking this question, but it's been bugging me for a while now.

When designing the BLL of a tiered application, would you put all your entity classes in one namespace? For example: If you have a database with Customers and their Vehicles and these Vehicles get Serviced on lets say a Monthly basis. I would think one would keep the Customers and their Vehicles in a separate 'module' from the 'services module' (so that if you ever need to update the way services are done or where the data is stored, you do not need to touch the Customer\Vehicle module).

Am I correct in thinking this way or should I change my design ideas?

This has presented me with a problem with using LINQ to SQL. If half of the tables' entity classes is contained in 'module' A and the other in 'module' B then somewhere you are going to have 'module' A reference 'module' B and vice versa to accommodate the associations between 2 tables that border with the 'modules'.

OR (just thought about this now) would you have 1 table's entity class overlap in the 'modules' (having the same class in both modules)?

Any advice would be appreciated.

Answer 1

It isn't completely clear if you also have a Data Access Layer because you mention "so that if you ever need to update the way services are done or where the data is stored, you do not need to touch the Customer\Vehicle module". The DAL would take care of handling the retrieving and storing the data, where ever that may be.

But of course it could be that Vehicle must be updated and it would be most convenient if updating those rules needed to be done in one place. You could simply create a Customer and Vehicle BLL with those rules. Then you just add a CustomerVehicleService that uses the Customer and Vehicle. There isn't a rule you can't.