设置视图模型需要许多服务层调用，这是正确的吗？
我的架构是这样的：UI 项目（MVC），连接到我的域服务层（业务规则等），连接到 Repo 层。
在设置视图模型时，我似乎对数据库进行了多次调用（9通过服务层）以在控制器内设置视图模型（即视图），这是正确的做法吗...
例如我有一个客户端，他们可以成为总部（复选框），如果他们成为/或者是总部，他们可以选择添加许多不同的客户。这个特定的视图将包含：客户端详细信息、要添加的可用客户端以及属于总部的当前客户端...
对我来说，似乎我应该检查域服务层中的每一项内容并向控制器返回什么它可以看到，即如果它是总部，那么它可以添加 x 数量的客户？？？
My architecture is thus: UI project (MVC), connected to my Domain Service Layer (Business rules etc), connected to a Repo Layer.
When setting up view models i seem to be making many calls to the database 9via service layer) to set up a viewmodel (i.e. view) within the controller, is this the correct thing to do...
E.g. I have a client, they can become a Head Office (checkbox), if they become/ or are a HeadOffice they have the option to add many different clients. This particular view will contain: The client details, Available clients to add and current clients that are part of the head office...
To me it appears as if I should be checking everying within the Domain Service Layer and giving back to the controller what it can see i.e. If it is a HeadOffice is has x number of clients it can add???
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我对这个问题并不完全确定，但这是我对这个问题的理解......
1）客户记录在所有情况下都将包含某些信息，并且您可以在一次通话中取回客户记录
2）如果客户记录具有 IsHeadOffice == true，您还可以选择加载“属于”“总部客户”的 IEnumerable 客户记录列表
我真的没有看到拨打两个电话有问题，一个电话打给“获取客户”方法一为“为总部用户获取客户”方法。
如果您愿意，您可以在服务层中将这些外观化并返回整个客户端，并在一次调用中返回所有关联的客户端。
如果您尝试将服务与 UI 绑定在一起，您将编写不必要的复杂方法来返回“完整”数据集。如果您从 UI 调用 50 个不同的方法，这可能会降低性能，并且您可能希望将其进一步聚合到堆栈中。
I'm not entirely sure on the question, but here is my understanding of the issue...
1) A client record will contain certain information in all cases, and you can get back a client record in one call
2) IF a client record has IsHeadOffice == true, you might additionally choose to load an IEnumerable list of client records that "belong" to the "head office client"
I don't really see a problem in making two calls, one to the "get client" method and one to the "get clients for head office user" method.
You could façade these in your service layer and return the entire client, with all associated clients in one call if you wish.
If you try and tie your service up with your UI, you will write unnecessarily complicated methods to return "complete" sets of data. If you are calling 50 different methods from the UI, that might not be performant and you might want to aggregate it further down the stack.