SOA 和 ASP.net MVC
我们正处于基于网络的保险系统的架构设计阶段（用于报价、保单管理、索赔管理、费率制定等）。该应用程序将由不同的模块组成。我们计划使用 ASP.Net MVC 和 SQL Server。对于业务逻辑层，我们有点困惑是使用 WCF 服务分离我们的 BLL 还是只是让 BLL 成为我们模型的一部分。我非常感谢您提出意见，说明为什么或为什么不在我们的情况下选择 SOA。
We are in architecture design phase of a web based Insurance System (for quoting, policy management, claims management, rate-making etc). This application would be comprises of different modules. We are planing to go with ASP.Net MVC and SQL Server. For business logic layer, we are bit confused whether to seperate our BLL using WCF services or just make BLL part of our Model. I would really appreciate your input why or why not go with SOA in our situation.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如果您绝对确定您的服务将被其他东西（SOA）消耗，但如果甚至出现了您不需要的情况，请练习 YAGNI。很多时候，有人会“以防万一”构建一个简单的 SOA 架构，但每次他们最终都会得到“为 ProductXXX 提供支持的服务”，而不是 SOA 架构。一旦发生这种情况，开发或维护产品的人们就会开始意识到，这些服务只是一种不必要的浪费，导致开发时间更长。
If you absolutely sure that your services are going to be consumed by something else, SOA, but if there is even a hit that you won't need it practice YAGNI. All too often someone will build out a simple SOA arch "just in case" and each and every time they end up with "the services that power productXXX" and not a SOA arch. Once that happens the people that are developing or maintaining the product start to realize that the services are just an unnecessary waste that is causing development to take longer.
在 MVC 应用程序中，大部分业务逻辑都位于模型中，而有些可能位于控制器中。 WCF 可用于制作数据服务层来支持您的模型/业务域。如果您认为保险系统及其数据将被 MVC 应用程序以外的任何内容消耗，那么您绝对应该采用支持面向服务的设计（即 WCF 服务）。
In an MVC app most of your business logic would be in the Model, while some may be in the controllers. WCF could be used to make data services layer to support your Model/business domain. If you think the Insurance System and it's data will be consumed by anything other than the MVC app, then you should definitely go with a design that supports service-orientation (ie; WCF services).