是否推荐混合使用2层和3层体系结构

Question

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

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

由于这是一种罕见的情况，所有数据(这是一个相当大的数量- SP本身需要大约6分钟来处理)是单个操作所需的，而且仅仅为了维护体系结构完整性而将所有数据作为对象提取到BLL中对我来说意义不大。此外，SP中的逻辑是迭代的，因此所有数据都需要在BLL中维护，并且不能有条件地获取。

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

Answer 1

@APC是正确的，逻辑应该放在最合适的地方- and：

• UI仍然应该通过BL层来获取数据，这样你的应用程序才能保持一致的结构化。
• 如果你要在应用程序中的不同位置有逻辑(为了满足某些要求，比如性能)，你应该清楚地记录这些主导因素是什么，并且应该很容易让后续的开发人员工作。

脑海中浮现出两个选项(关于结构)：

• 确保应用程序结构合理和清晰的一种方法是通过接口隔离特定的“繁重”任务。理想情况下，您的所有数据访问都应该已经由接口抽象出来，并且这些接口应该被划分为逻辑区域(请参阅Interface Segregation Principle - ISP)。因此，您可以为特定的数据访问需求提供专用的接口: BL -> IDataAccess ->具体的数据调用方法(但方式类似)：不是让BL像常规数据访问那样访问这些特殊的数据调用，而是将其作为BL包含或注入。

如何执行第二种方法:定义一个接口(在BL层中)，该接口将被其他业务对象使用: BL Object -> ISpecialBusinessLogic ->具体实现。具体的业务逻辑可以是任何东西-但在您的示例中，它将是对一个特殊数据访问方法/组件的调用，您可以在该方法/组件中执行“繁重工作”。

当您实现数据访问时，您可以选择在单个类/组件(实现多个接口)或单独的类/组件(每个类/组件实现一个接口)中完成所有这些操作。

Answer 2

业务逻辑属于最合适的地方。如果您有与数据相关的逻辑，并且只由存储过程执行，那么数据库是保存它的合适位置。

Answer 3

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

此外，将来，如果您需要对SP返回的数据应用某些业务逻辑，则可以在BL中执行此操作。