c# - 调用业务层方法

Question

我对多层架构和 asp.net mvc 很陌生。 我想知道调用业务层方法的最佳做法是什么。

1) 从 Controller 调用业务层方法，填充 View 模型并将 View 模型传递给 View 。

2) 直接从 View 中调用业务层方法。

请让我知道这两种方法的优缺点。 如果解释一下“在哪些场景下使用这两种方法”，将不胜感激

Answer 1

这接近于征求意见的问题，但我认为值得解释一下，尽管您可以通过足够的研究找到它。

选项 1 是要走的路，可能 +80% 同意了这一点。

如果再这样，您会遇到“视情况而定”的答案。这取决于你需要打破多少东西。在学术上，你应该松散耦合，具有高凝聚力。一切都很好，但在现实世界中很少有绝对的，因为完美的架构更多的是“及时”设计而不是学术问题，否则你永远不会把东西投入生产。因此，作为开发人员，您必须就您妥协的地方做出判断(并且您会)。

所以这是它基于意见的地方:

a) 具有高内聚性的松散耦合意味着更好的可测试性/可维护性/可扩展性，但代价是更大的抽象，即更多的前期开发时间。

b) 反过来意味着更少的商品，但也意味着更少的前期开发时间，也就是“把它拿出来，不要再告诉我(你的老板)好的架构该死的!”

一个优秀的开发人员总是努力争取 a)。问题是我们大多数人必须在取得进步之间取得平衡，所以我们倾向于滑向 b)(不情愿地)

因此，为了进一步讨论(如果您仍在阅读)...a) 的示例，还有很多其他正确的 a，这只是一种风格:

您的 View 模型应该包含渲染 UI 所需的所有内容， View 所需的最少数据 + 直接从 UI 调用的函数。它不应该代表与域模型有关的业务逻辑。领域模型应该代表代表它们所包含的领域所必需的数据。业务逻辑层，这里指的是服务层，应该是对域进行操作的功能。

例子:

假设我们有一个拥有多个帐户的用户。会有一个用户类和帐户类。这些组合在 UserAccounts 类(用户属性和帐户属性(数组))中。

根据您决定域的方式，可以使用 UserService 类或 UserService + AccountService + UserAccountService 类组合。

然后假设您有用户(UserView 类)和用户详细信息(UserDetailView 类) View 。 UserView是User类+账户的聚合表示(但不是所有细节)+UI直接调用功能。 UserDetailView代表User+各个账号详情+UI直呼功能。

User Controller 有两个函数(肯定还有很多，但只是为了解释)，getUsers 和 getUserDetail。

• GetUsers 调用返回 UserAccounts 对象数组的用户服务 然后通过返回 UserView 数组的模型构建器传递 Controller 随后传递给“摘要” View 的对象。
• GetUserDetail 调用返回 UserAccounts 的用户服务 然后通过返回一个模型构建器的对象 Controller 随后传递给的 UserDetailView 对象 “详细” View 。