2

我正在使用 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 提到的实用程序类或扩展方法中

4

5 回答 5

3

我不喜欢控制器中的任何真实逻辑。因此，如果您想将其分开，我会将其移至现有的 BLL，甚至是 BLL 中的新组件。

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

首先，这种逻辑往往会失去控制，它会真正使您的控制器操作变得混乱。我喜欢它们非常简洁。（我通常会在其中发生三件事——身份验证、数据检索、视图模型构建。这些都是通过以某种形式的 BLL 调用单个方法来实现的。）

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

于 2014-01-22T12:26:14.143 回答
2

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

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

我已经完成了一个嵌入逻辑的视图。然后我看到了这些观点的演变。这不漂亮。最终将所有逻辑从视图中剔除并将其放入QueryHandler<T>. 所以我的经验法则是在 BLL 中进行所有计算（如果您使用的是CQRS ，则使用查询处理程序）。只需将准备好的数据提供给视图。（这种方法也最大限度地减少了对映射层的需求）。这样你的视图只有一个单一的职责——以所需的格式显示数据。

至于映射层，我更喜欢那里有最少的逻辑。我允许DateTime将其转换为String格式2 Feb 2014，但除此之外，您又遇到了麻烦。

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

于 2014-01-22T14:58:04.097 回答
1

但在其他情况下，计算只会用于一个视图。在这种情况下，计算是否应该进入控制器

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

如果我可以概括一个计算并多次使用它，它应该进入 BLL，

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

于 2014-01-22T12:09:21.780 回答
1

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

于 2014-01-22T12:10:49.210 回答
0

编写为实用函数并用于业务层的通用函数应该会有所帮助。让我们也听取其他人的意见

于 2014-01-22T12:27:27.777 回答