我正在构建一个基于 SOA 的应用程序。我有一堆业务服务，我应该将它们作为组件提供给其他应用程序（所以我将使用 Web 服务 -SOAP-）。
应用表示层是MVC。
1- 模型：包含数据库方法（使用 ORM）。
2- 控制器：包含对模型方法的调用以及处理简单视图操作的方法。
3- 视图：仅包含渲染内容。
那么，你能给我一个简单的场景，我如何将 Web 服务与我的 MVC 应用程序结合起来，我的建议是将模型分离为 Web 服务，对吗？
【问题讨论】：
标签： asp.net asp.net-mvc web-services soap ado.net-entity-data-model
我会这样处理：(YMMV)
构建一个数据层组件来容纳您的所有数据访问。称它为 DAL。它将包含所有数据访问方法。这将启用重用，但也允许以下一个应用程序使用的方法。这是您的 EF 模型可以存在的地方。
构建 2 个 Web 项目：MVC 和 Web 服务。每个人都将实现业务逻辑以满足各自的需求。他们会根据需要引用并调用 DAL 以进行数据访问。正如您所指出的，它们都是表示层服务。一个有用户界面，另一个是远程 Web 服务消费者的通信端点。
根据需要将两者部署到应用服务器上。建议在 IIS 中创建 2 个应用程序/站点 - （即“Web”和“WebServices”）。这种应用程序的分离确保了一个可以更改/停机/版本控制而不影响另一个。
MVC 项目/应用程序仍将照常拥有其模型、视图和控制器。这里最大的变化是模型将仅根据需要用于 ViewModel。它将包含任何满足 UI 要求的业务逻辑。它的控制器方法会根据需要调用适当的 DAL 公共方法。
Web 服务项目/应用程序将能够根据需要独立更改，而数据访问权限将保持不变。
【讨论】：
1) 将所有服务操作放在接口后面。
2) 考虑使用控制反转容器在您的应用程序中利用依赖注入。这使您可以更轻松地模拟您的依赖项并单元测试您的控制器逻辑。一些例子是Windsor、Ninject、StructureMap。
3) 考虑为您的视图使用强类型视图模型，而不是您的 ORM 使用的对象。您需要设置一些映射类来帮助管理此问题，但使用AutoMapper 之类的东西可以消除很多痛苦。
这里有一些关于这个主题的好链接：
【讨论】：
永远不要为了使用 Web 服务而使用 Web 服务：您首先应该有一个需要解决的问题，并看到 Web 服务是解决您问题的最佳方法。因此，根据您的需要，可以以多种不同的方式使用 Web 服务。
例如，既然您说 MVC 是您的表示层，您可能希望将 Web 服务作为层插入模型和控制器之间。控制器不是直接调用您的模型（数据层），而是调用您的 Web 服务并为服务提供基于 Web 的前端，否则这些服务可以通过您的 SOAP API 获得。
另一种选择是让 MVC 前端和 SOAP 服务都访问一个通用的业务/数据逻辑层，每个服务都为相同的后端提供自己的“API”。
但我再次强调：Web 服务不应该用作寻找问题的解决方案。如果您不清楚 Web 服务应该适合您的架构的哪个位置，那么没有它们您可能会更好。
【讨论】：