带有 Web 服务的 MVC
我正在致力于构建一个基于 SOA 的应用程序。我有一堆业务服务，我应该将它们作为组件提供给其他应用程序（因此我将使用 Web 服务 -SOAP-）。
应用程序表示层是MVC。
1-模型：包含数据库方法（使用ORM）。
2- 控制器：包含对模型方法的调用以及处理简单视图操作的方法。
3-视图：仅包含渲染内容。
那么，您能否给我一个简单的场景，如何将 Web 服务与我的 MVC 应用程序结合起来，我的建议是将模型分离为 Web 服务，对吗？
I'm working on building an application that's based on SOA. I have bunch of business services that I should make them available as components to another applications (so I'll use web services -SOAP-).
The application presentation layer is MVC.
1- Model: Contains DataBase methods (ORM is used).
2- Controller: Contains calls to the model methods as well as methods to handle simple view actions.
3- View: Contains rendering content only.
So, can you give me a simple scenario how can I combine web service with my MVC application, my suggestion is to separate the model as web services, is that right?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我会这样解决这个问题：(YMMV)
构建一个数据层程序集来容纳所有数据访问。称之为 DAL。它将包含所有数据访问方法。这将实现重用，但也允许下面一个应用程序使用的方法。这是您的 EF 模型可以生存的地方。
构建 2 个 Web 项目：MVC 和 Web 服务。每个人都将实现业务逻辑来满足各自的需求。他们会根据数据访问的需要引用和调用 DAL。正如您所指出的，它们都是表示层服务。一个具有用户界面，另一个是远程 Web 服务使用者的通信端点。
根据需要将两者部署到应用程序服务器上。建议在 IIS 中创建 2 个应用程序/站点（即“Web”和“WebServices”）。这种应用程序的分离确保了一个应用程序可以更改/停机/版本控制，而不会影响另一个应用程序。
MVC 项目/应用程序仍将正常拥有其模型、视图和控制器。这里最大的变化是模型将仅根据需要用于 ViewModel。它将包含满足 UI 要求的任何业务逻辑。它的控制器方法将根据需要调用适当的 DAL 公共方法。
Web 服务项目/应用程序将能够根据需要独立更改，而数据访问权限将保留。
I'd tackle it this way: (YMMV)
Build a data tier assembly housing all your data access. Call it the DAL. It will contain all data access methods. This will enable re-use, but also allow for methods used by one application below. This is where your EF model can live.
Build 2 web projects: MVC and web services. Each will implement business logic to satisfy their respective requirements. They'd reference and call into the DAL as needed for data access. As you noted, they're both presentation-tier services. One has a user interface, the other is a communication endpoint for remote web service consumers.
Deploy both onto an application server as needed. Suggest creating 2 applications/sites in IIS - (i.e. "Web" and "WebServices"). This separation of applications ensures that one can be changed/downtimed/versioned without effecting the other.
The MVC project/app will still have its Models, Views and Controllers as per normal. The biggest change here is that the Models would be used only for ViewModels as needed. It would contain any business logic to satisfy the UI requirements. Its controller methods would call the appropriate DAL public methods as needed.
The web services project/app would be able to be changed independently as needed, while the data access would remain.
1) 将所有服务操作放在一个接口后面。
2) 考虑使用控制反转容器在应用程序中利用依赖注入。这使您可以更轻松地模拟依赖项并对控制器逻辑进行单元测试。一些示例是 温莎、Ninject，StructureMap。
3) 考虑对视图使用强类型视图模型，而不是 ORM 使用的对象。您需要设置一些映射类来帮助管理此问题，但是通过使用类似 自动映射器。
以下是有关该主题的一些很好的链接：
1) Place all your service operations behind an interface.
2) Consider using an Inversion of Control container to utilize dependency injection in your application. This allows you to mock your dependencies and unit test your controller logic more easily. Some examples are Windsor, Ninject, StructureMap.
3) Consider using strongly type view models for your views, instead of the objects that your ORM works with. You'll want to set up some mapping classes to help manage this, but a lot of the pain can be taken away by using something like AutoMapper.
Here's some good links on the subject:
永远不要为了使用 Web 服务而使用 Web 服务：您应该首先有一个需要解决的问题，然后看看 Web 服务是解决您问题的最佳方案。因此，根据您的需要，可以通过多种不同的方式使用 Web 服务。
例如，既然您说 MVC 是您的表示层，那么您可能希望在模型和控制器之间插入 Web 服务作为层。控制器不是直接调用您的模型（数据层），而是调用您的 Web 服务并为服务提供基于 Web 的前端，否则这些服务可通过 SOAP API 获得。
另一种选择是让 MVC 前端和 SOAP 服务都访问公共业务/数据逻辑层，每个层都为同一后端提供自己的“API”。
但我再次强调：Web 服务不应该被用作寻找问题的解决方案。如果您不清楚 Web 服务应该在您的架构中的什么位置，那么没有它们您很可能会过得更好。
Never use web services for the sake of using web services: You should first have a problem that needs solving, and see that web services are the best solution to your problem. So depending on your need, web services can be used in a variety of different ways.
For example, since you say MVC is your presentation layer, you may want to insert web services as a layer between the Model and the Controller. Rather than invoking your model (data layer) directly, the Controller invokes your web services and provides a web-based front-end to the services that would otherwise be available via your SOAP API.
Another option is to make both your MVC front-end and the SOAP services access a common business/data logic layer, each providing their own "API" for the same back-end.
But again I emphasize: web services should not be used as solution in search of a problem. If it's not obvious to you where the web services should fit into your architecture, you are very likely better off without them.