Separation of business logic [closed]

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 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!