是推荐使用2和3层架构的混合体

Question

我正在创建一个Web应用程序，它将各种业务规则作为输入并将它们存储在数据库中。这是使用3层架构完成的。

之后我必须在一个操作中使用所有这些业务规则，因此我在存储过程中编写此部分的业务逻辑，并从UI调用它使其成为2层。

由于这是一种罕见的情况，单个操作需要所有数据（这是一个相当大的数量 - SP本身需要大约6分钟来处理），因此将所有数据提取为将对象放入BLL只是为了维护架构的完整性。此外，SP中的逻辑是迭代的，因此所有数据都需要在BLL中维护，并且无法有条件地获取。

如果我有正确的方法，请建议我。

Answer 1

@APC是正确的，逻辑应该存在于最合适的地方 - 并且：

• UI仍应通过BL层获取数据，以便您的应用程序始终如一。
• 如果您要在应用程序中的不同位置使用逻辑（为了满足某些要求，如性能），您应该清楚地记录这些管理因素是什么，并且后续开发人员应该很容易解决。

有两种选择（关于结构）：

• 确保应用程序结构合理且清晰的一种方法是通过界面隔离特定的“繁重”任务。理想情况下，所有数据访问都应该已经被接口抽象出来，这些应该被分解为逻辑区域（参见Interface Segregation Principle - ISP）。因此，您可以拥有满足特定数据访问需求的专用接口：[BL] - ＆gt; [IDataAccess] - ＆gt; [具体数据访问]
• 另一种方法（但也是类似的）：不是让BL访问这些特殊数据调用，如常规数据访问，包括或注入它作为BL。

如何进行第二种方法：定义将由其他业务对象使用的接口（在BL层中）：[BL Object] - ＆gt; [ISpecialBusinessLogic] - ＆gt; [具体实施]。具体的业务逻辑可以是任何东西 - 但在你的情况下，它将是一个特殊的数据访问方法/组件的调用，你做“繁重”。

当您实现数据访问时，您可以选择在单个类/组件（实现多个接口）中执行所有操作，也可以选择单独实现单个接口的类/组件。

Answer 2

业务逻辑属于最合适的地方。如果您具有与数据关联的逻辑，并且该逻辑仅由存储过程执行，则数据库是保存它的适当位置。

Answer 3

我假设您的应用程序的其他模块也维护3-tie架构。因此，为了保持一致性和可维护性，您应该保持3层架构。

此外，将来，如果您需要对SP返回的数据应用一些业务逻辑，那么您将在BL中执行。