业务逻辑分离

Question

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

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

Database <-> DAL <-> BLL 

Dal使用业务对象传递给BLL，BLL再将其传递给使用此dll的应用程序。

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

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

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

我想到的第一件事是，将bll移动并分离到我可以包含在我的应用程序中的其他dll。但是Dal必须是公共的，这样其他dll才能获得数据...我看起来是个不错的解决方案。

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

所以我在征求你的意见。

Answer 1

我同意@MikeC。为每个段在名称空间中分隔BLL。另外，也要将DAL分开，如下所示：

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

另一件要做的事情，是用分离dll的。这样，您就不需要公开DAL了。它将是一个业务层(类似于WCF或Web服务)，负责每个系统的动态链接库和DAL，使的支持和维护更容易。我不知道这是不是你们公司目前最实惠的方法(就复杂性而言)，但对于设计而言，这是一种更好的方法，。

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

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

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想法只是一个 idea ！

Answer 2

对于每个业务的“细分”，你应该有一个不同的BLL和DAL…例如：

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

Answer 3

我建议你将你的业务逻辑按照它们的性能划分到不同的dll中(根据上一篇文章)，这些类将实现特定的接口，而这个接口将在你的业务登录消费者上声明。然后我建议你实现容器(参见控制反转理论)来解决dll实现，这将允许你将业务逻辑实现从消费中分离出来，你将能够毫不费力地将一些实现替换为另一个实现。

我为在IoC中使用provider进行辩护，而不是直接使用业务管理器类(想想可能导致噩梦的引用)。该方案解决了动态链接库的隔离和优化消耗的问题。