0

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.

tkl33
  • 313
  • 1
  • 2
  • 9

2 Answers2

2

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.

detroitpro
  • 3,853
  • 4
  • 35
  • 64
  • 1
    In my experience, listing out "services that power product XXX" is the point of SOA. Many systems start out without an SOA, and only implement one when it becomes unwieldy to maintain. At the point, the benefit of an SOA is not just about creating a common infrastructure, but forcing you to actually design out how your applications interact, and that might mean simplifying and refactoring things so that you end up with "services that power XXX"... and that's perfectly okay. – Joel Coehoorn Dec 14 '12 at 19:54
1

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).

Carol Skelly
  • 351,302
  • 90
  • 710
  • 624