Separation of business logic

Question

When I was optimizing my architecture of our applications in our website, I came to a problem that I don't know the best solution for.

Now at the moment we have a small dll based on this structure:

Database <-> DAL <-> BLL 

the Dal uses Business Objects to pass to the BLL that will pass it to the applications that uses this dll.

Only the BLL is public so any application that includes this dll, can see the bll.

In the beginning, this was a good solution for our company. But when we are adding more and more applications on that Dll, the bigger the Bll is getting. Now we dont want that some applications can see Bll-logic from other applications.

Now I don't know what the best solution is for that.

The first thing I thought was, move and separate the bll to other dll's which i can include in my application. But then must the Dal be public, so the other dll's can get the data... and that I seems like a good solution.

My other solution, is just to separate the bll in different namespaces, and just include only the namespaces you need in the applications. But in this solution, you can get directly access to other bll's if you want.

So I'm asking for your opinions.

Answer 1

You should have a distinct BLL and DAL for each "segment" of business... for example:

• MyCompany.HumanResources.BLL
• MyCompany.Insurance.BLL
• MyCompany.Accounting.BLL

Answer 2

I suggest you to separate your business logic into different dll's in accordance to their pertence (in accordance with previous post), these classes will implement specific interface while this interface will be declared on you business login consumer. Then I suggest you to implement the containers (see Inversion of Control theory) to resolve dll implementation, this will allow you to separate business logic implementation from consumption and you will be able to replace some implementation by another, without difficulty.

I defend the use of provider with IoC and not the consumption of business manager classes directly (think about references which can result in nightmare). This solution resolves the problem of dll's isolation and their optimized consumption.

Answer 3

I agree with @MikeC. Separate the BLL in namespaces, for each segment. Also, separate the DAL too, like this:

• MyCompany.HumanResources.DAL
• MyCompany.Insurance.DAL

Another thing to do, is separate the dll's. This way, you dont need to make DAL public. It will be a Business Layer (like WCF or Web-service), responsible of BLL and DAL, for each system, making the support and maintenance more easy. I dont know if its the most affordable approach for your company right now (in terms of complexity), but its a better approach for design purposes.

Times before, the applications developed here in the company, used component architeture - sharing the components trough applications -. We realized that, it wasnt the best design and today, many systems (in production enviroment) use that design approach.

Furthermore: If you want more complexity, you could also generate a Generic dbHelper component, responsible to maintain the data access, including operations that controls the connections, commands and transactions. This way, preventing the rewrite of code. That assembly could makes use of Enterprise Library or others components. An operation example could be:

public DbCommand CreateCommand()
    {
        if (this._baseCommand.Transaction != null)
        {
            DbCommand command = this._baseConnection.CreateCommand();
            command.Transaction = this._baseCommand.Transaction;
            return command;
        }
        return this._baseConnection.CreateCommand();
    }

You can make it virtual, implementing a SqlCommand CreateCommand and so on.

Remembering: the Generic dbHelper idea I exposed, is just an idea!

Answer 4

It sounds like you have common business logic, that applies the your organization in general, and more specific logic per section or department. You could set up your code in a way so that each dept. only depends on their specific logic, which behind the scenes uses any generic functionality in the "base" logic. To that end, you could set up the following projects:

• Business.BLL
• Business.Finance.BLL
• Business.IT.BLL
• (etc, ad infinitum, and so on...)

Note that each of these can be a separate project, which compiles to its own assembly. A department would only need to use their own assembly.

As far as data access goes, you can have generic data access routines in your base BLL. Your specific BLLs can have their own specialized data queries that are funnelled to the base BLL, which in turn uses the generic DAL and returns results back up the chain.