Business Logic Layer Design

Question

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.

Thanks

Posted 6-Oct-11 5:01am

PJ du Preez

Add a Solution

4 solutions

Solution 3

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:
http://msdn.microsoft.com/en-us/library/aa581779.aspx[^]

Good luck!

Posted 6-Oct-11 6:51am

E.F. Nijboer

Comments

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.

Solution 2

I would keep the whole database in one model until there is a good reason not to:

KISS[^]

YAGNI[^]

Posted 6-Oct-11 6:35am

Nicholas Butler

Comments

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?

Solution 4

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.

Posted 6-May-13 21:37pm

Ehsan yazdani rad

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

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

CodingLover · Accepted Answer · 2011-10-06T06:28:00

Solution 1

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.

Posted 6-Oct-11 6:28am

CodingLover

Comments

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.