Click here to Skip to main content
14,698,806 members
Please Sign up or sign in to vote.
5.00/5 (1 vote)
See more:
Hi there,

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.


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.

Maybe this link could also help you:[^]

Good luck!
PJ du Preez 6-Oct-11 13:16pm
Thanks for the link. it seems worth a read. My project does consist of a DAL. I'm using a DataContext implementation together with mapping generated by sqlmetal (i like the idea of POCO). between this and my BLL I have a repository to keep the two areas apart to prevent circular dependencies.
I agreed.

In general each BLL implement on different modules. As you said in different namespases or simply projects. So that the changes you have to do in later cases are minimal. However it depends on how your interface (means the handling accessors on each namespaces) is implemented on each module for communicating between them.

I think those architectural implementation based on your skills and experience. Because you can customize as you wish in many ways.

When comes to the database structures, I prefer to maintin a flat structure with relevant primary keys. Then I don't want to worry about the DBMS alternations as well.
PJ du Preez 6-Oct-11 13:03pm
thanks for the reply. my 'solution' does contain various 'projects' and I like the design. there are projects that depend on others (based on their tables' relationships in the database) the design without LINQ2SQL works perfect as the other projects do not know about the one that depends on it, but when implementing L2S the 'independent' modules then needs Entity Refs and Set of classes from the 'dependent' module thus creating a circular dependency. any ideas?
CodingLover 7-Oct-11 2:44am
If you can keep one project as the DAL (Data Access Layer), and do all the database manipulations through that. As I said defining a public interface for that DAL in order to communicate to/from other modules.
I would keep the whole database in one model until there is a good reason not to:


PJ du Preez 6-Oct-11 13:09pm
well I have spent quite a decent amount of time determining what will be needed and how to break the database into simpler 'smaller' structures for the individual modules. by this I mean it is in one model, but you can easily identify which table clusters belong to which module (they are all related in some way anyways) could it possibly be simpler?
Nicholas Butler 6-Oct-11 13:28pm
Unless you have thousands of tables, I think you're over-engineering this.

You're finding it difficult to split the tables into groups that are isolated - where's the gain?
As my experiences , when using EF on L2S or other context base data source that break into model and context, placing it inside the DAL is better approach compare to adding BL reference to DAL. in addition for better decoupling, I always define interface for Data Model in DAL and use it in Business Entity in BL.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900