Separation of business logic

Question

When I optimized my architecture of our applications on our website, I ran into the problem that I do not know a better solution.

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

Database <-> DAL <-> BLL 

Dal uses Business Objects to navigate to the BLL, which will pass it on to applications using this DLL.

Only BLL is publicly available, so any application that includes this DLL can see bll.

In the beginning, it was a good decision for our company. But as we add more and more applications to this Dll, the more Bll becomes. Now we do not want some applications to be able to see Bll logic from other applications.

Now I do not know what is the best solution for this.

The first thing I thought: move and split the bll to another dll, which I can include in my application. But then the Dal should be public, so another dll can get the data ... and that I think is a good solution.

My other solution is to simply split the bll in different namespaces and just include only those namespaces that you need in the applications. But in this solution, you can directly access another bll if you want.

So, I ask for your opinion.

Answer 1

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

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

Another thing is to separate the dll . This way you do not need to publish DAL. This will be the business layer (e.g. WCF or web service) responsible for BLL and DAL for each system, simplifying support and maintenance . I don’t know if its the most affordable approach for your company right now (in terms of complexity), but is better suited for design purposes .

In advance, the applications developed here at the company used a component architecture - sharing components through applications . We realized that this is not the best design, and today many systems (in the production environment) use this design.

In addition: if you need extra complexity, you can also create a common dbHelper component, which is responsible for maintaining data access, including operations that control connections, commands and transactions. Thus, preventing code rewriting. This assembly may use the Corporate Library or other components. Operation example:

 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, implement SqlCommand CreateCommand, etc.

Recalling: The general idea of ​​dbHelper that I revealed is just an idea !

Answer 2

You must have a separate BLL and DAL for each "segment" of the business ... for example:

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

Answer 3

I suggest that you divide your business logic into different dlls according to their need (according to the previous post), these classes will implement a specific interface, while this interface will be declared in your business logic. Then I suggest you implement containers (see "Theory of Management Inversion") to solve the dll implementation, this will allow you to separate the implementation of business logic from consumption, and you can easily replace any implementation with another.

I protect the use of the provider with IoC, and not by using the classes of the business manager directly (think of links that can lead to a nightmare). This solution solves the problem of dll isolation and their optimized consumption.

Answer 4

It looks like you have a common business logic that applies your organization as a whole and more specific logic for each section or department. You can customize your code so that each department. depends only on their specific logic, which behind the scenes uses any common functions in the "basic" logic. For this purpose, you can set up the following projects:

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

Please note that each of them can be a separate project that compiles into its own assembly. The department will have to use its own assembly.

Regarding data access, you can have general data access procedures in your base BLL. Your specific BLLs may have their own specialized data queries that are routed to the underlying BLL, which in turn uses a common DAL and returns the results to the chain.