Question

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

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

Database <-> DAL <-> BLL

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

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

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

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

我想到的第一件事就是移动并将bll分离到我可以包含在我的应用程序中的其他dll。但是必须让Dal公开，所以其他dll可以得到数据......而且我似乎是一个很好的解决方案。

我的另一个解决方案是将不同名称空间中的bll分开，只包含应用程序中所需的名称空间。但是在此解决方案中，如果需要，您可以直接访问其他bll。

所以我要求你的意见。

Answer 1

对于每个业务“细分”，您应该有一个独特的BLL和DAL ...例如：

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

Answer 2

我同意@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想法，只是一个想法！

Answer 3

我建议你根据它们的相关性（根据之前的帖子）将你的业务逻辑分成不同的dll，这些类将实现特定的接口，而这个接口将在你的业务登录消费者上声明。然后我建议你实现容器（参见Inversion of Control理论）来解决dll实现，这将允许你将业务逻辑实现与消费分开，你将能够毫无困难地用另一个替换一些实现。

我使用IoC来保护提供者的使用而不是直接消费业务经理类（想想可能导致噩梦的引用）。该解决方案解决了dll隔离问题及其优化消耗。

Answer 4

听起来你有一个共同的业务逻辑，它适用于你的组织，每个部门或部门都有更具体的逻辑。您可以通过某种方式设置代码，以便每个部门。仅取决于他们的具体逻辑，其在幕后使用“基础”逻辑中的任何通用功能。为此，您可以设置以下项目：

Business.BLL
Business.Finance.BLL
Business.IT.BLL
（等等，无限广告，等等......）

请注意，每个项目都可以是一个单独的项目，它可以编译为自己的程序集。部门只需要使用自己的装配。

就数据访问而言，您可以在基本BLL中使用通用数据访问例程。您的特定BLL可以拥有自己的专用数据查询，这些查询汇集到基本BLL，后者又使用通用DAL并将结果返回到链中。

业务逻辑的分离

4 个答案: