分离业务逻辑(Separation of business logic [closed])

分离业务逻辑(Separation of business logic [closed])

当我在我们的网站上优化我们应用程序的架构时，我遇到了一个问题，我不知道最佳解决方案。

现在我们有一个基于这个结构的小dll：

Database <-> DAL <-> BLL

Dal使用Business Objects传递给BLL，BLL将把它传递给使用这个dll的应用程序。

只有BLL是公共的，因此任何包含此dll的应用程序都可以看到bll。

一开始，这对我们公司来说是一个很好的解决方案。 但是，当我们在该Dll上添加越来越多的应用程序时，Bll越来越大。 现在我们不希望某些应用程序可以从其他应用程序中看到Bll逻辑。

现在我不知道最好的解决方案是什么。

我认为的第一件事是，将bll移动到其他dll中，我可以将其包含在我的应用程序中。 但是，那么Dal必须是公开的，所以其他的dll可以获取数据......而且我似乎是一个很好的解决方案。

我的另一个解决方案就是将bll分隔在不同的名称空间中，并且只包含应用程序中需要的名称空间。 但是在这个解决方案中，如果你愿意，你可以直接访问其他的bll。

所以我在征求你的意见。

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.

最满意答案

我同意@MikeC。 将名称空间中的BLL分隔为每个段。 此外，还要分离DAL，如下所示：

MyCompany.HumanResources.DAL MyCompany.Insurance.DAL

另一个要做的事情是将dll分开 。 这样，你不需要公开DAL。 它将成为每个系统的业务层（如WCF或Web服务），负责BLL和DAL，使支持和维护更加容易 。 我不知道它是否是目前贵公司最经济实惠的方法（就复杂性而言），但它是用于设计目的的更好方法。

以前，在公司开发的应用程序，使用组件架构 - 通过应用程序共享组件 - 。 我们意识到，它不是最好的设计，今天许多系统（在生产环境中）都使用这种设计方法。

此外：如果您想要更复杂一点，您还可以生成一个通用dbHelper组件，负责维护数据访问，包括控制连接，命令和事务的操作。 这样，防止重写代码。 该程序集可以使用Enterprise Library或其他组件。 操作示例可以是：

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

您可以将其设置为虚拟，实现SqlCommand CreateCommand等。

记住：我公开的通用dbHelper理念只是一个想法 ！

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!