Question

我正在使用n层方法构建ASP.Net MVC Web应用程序。我的结构看起来像这样：

Business Objects - Model
Data Access Layer - DAL
Business Logic Layer - BLL
Mapping Layer
ViewModels
Controllers
Views

我通常将计算放在业务层中，但是那些仅用于演示目的的计算呢？例如，在我的应用程序中的视图中，我显示了发票总额，任何付款和余额欠款。余额欠款是一个计算金额。由于我在我的应用程序中多次使用Balance Owing，我倾向于在我的BLL中创建一个通用的BalanceOwing方法，但是在其他情况下，计算只会用于一个视图。在这种情况下，计算应该在控制器中，还是在我的情况下是映射层？（我有一个映射层，用于将域模型转换为视图模型。它使控制器更整洁）。

这真的是分界线吗？也就是说，如果我可以推广计算并多次使用它，那么它应该进入BLL，但如果它特定于一个视图，它应该在控制器或映射器中？

概要

我选择了@ trailmax的答案，因为他看到我认为是表示逻辑的一些东西实际上是业务逻辑，因此属于BLL。如果某些东西确实是表示逻辑并且涉及分页等计算，我会将它们放在@ramiramilu提到的实用程序类或扩展方法中

Answer 1

我不是控制器中任何真实逻辑的粉丝。所以，如果你想把它分开，我会把它移到现有的BLL，甚至是BLL中的一个新组件。

我采用这种方法的原因有两个。

首先，这种逻辑趋于失控，它会使控制器动作变得混乱。我喜欢他们非常简洁。（我通常会发生三件事 - 身份验证，数据检索，ViewModel构造。这些都是通过在某种形式的BLL中调用单个方法来实现的。）

第二个原因是因为控制器动作更难以进行单元测试，特别是如果它们有很多混乱的逻辑。以这种方式构建我的控制器动作确实有助于良好的单元测试实践。

Answer 2

这一切都归结为您认为的“视图特定”。如果这是计算屏幕分辨率或浏览器版本 - 那绝对是。如果你谈论的持续时间很简单，我会三思而后行。它可能看起来很简单，但实际上将来可以发展 - 只需将其保留在BLL中。

在评论中，您提到了持续时间。这可能看起来很简单(End - Start).Date。但是这可能会在以后计算出这个时期的持续时间，不包括周末（例如）。这绝对是BLL，甚至不是Mapping层。

我已经完成了嵌入逻辑的视图。然后我看到这些观点在不断发展。这不太好看。结束了将所有视图中的逻辑删除并将其放入QueryHandler<T>。因此，我的经验法则是在BLL（或查询处理程序，如果您使用CQRS）中进行所有计算。只需将准备好的数据提供给视图即可。（此方法也最大限度地减少了对映射层的需求）。这样，您的视图只具有单一职责 - 以所需格式显示数据。

至于映射层，我更喜欢那里有最小的逻辑。我允许DateTime转换为格式为String的{{1}}，但除此之外的任何内容都会再次出现问题。

分页是一个展开的概念。它不是真正的商业逻辑，也不是视图的责任。但是因为它在应用程序中如此深入，所以无论如何都会以BLL结束（或者在我们的例子中是查询处理程序）。

Answer 3

但是在其他情况下，计算才会发生用于一个视图。在这种情况下，应该进行计算控制器

是的，不仅一次使用计算，而且仅用于演示的计算应该进入表示层本身。您的业务层应该对业务需求和要求透明。您可以做的是创建简单的实用程序或扩展文件夹，并将所有最常用的表示层计算放在那里并重用它们。

如果我可以概括一个计算并且不止一次地使用它进入BLL，

不完全是，如果该计算具有业务相关性和重要性，那么它应该进入BLL。否则它应该保持在演示级别本身。

Answer 4

在我看来，最好在一个地方完成所有业务逻辑，并将业务层垂直划分（即更细粒度的服务层类），而不是水平划分（更多层）。我认为，如果您的某些业务逻辑是特定于视图的，那么这不是问题，因为您仅在Web表示层上使用它。保持简单愚蠢而不是过度设计：）

Answer 5

作为效用函数编写并在业务层中使用的泛型函数应该有所帮助。让我们也听听别人的意见

业务层或控制器中的视图特定信息的计算

5 个答案: