SOA/WCF design considerations RRS feed

  • Question

  • User-2009101617 posted

    I'm working on redesigning my company's application architecture.  Currently most apps are old web forms stuff with all layers in one tier (don't laugh too hard).  The new design is a SOA design using MVC UI projects for the front end a WCF service for the business tier and a data service for the data tier (allows for multiple DB servers and distributed databases to be access with a single interface).  The question that I have is in the design of the business tier.  My idea is to create a single business service that exposes all business methods and that all the UI projects will use.  There are some common services that will be used by many apps and then there are app specific services.  So, my idea to have a single service containing all service methods has a problem in that the contract could change frequently and I don't want to have to update every app (about 150 of them) when the service contract changes.  I could create multiple contracts but that goes against the simple single service reference that I want the developers to use.  It's easier to just use a single service reference than to have to use multiple.   So, is there a way to accomplish this without having to update all the UI projects everytime there is a change to the business service?  I'm interested in how other may have tackled this problem.

    Monday, December 16, 2013 9:54 AM


  • User-488622176 posted

    There is no best way to do this. Everything is a tradeoff. You can get some insights on how to design services here : http://blogs.msdn.com/b/nickmalik/archive/2005/10/07/478230.aspx

    An often used approach in large SOA context is to use a service interface per use case. Every interface contains the methods to implement the use case. You can map every use case in a specific domain to a service component (implementation class). But at least you have a set of clean and structured service interfaces. Changes are also limited to either a changed use case, or have no impact when you add a new service interface for a new use case.

    Your proposal to make 1 service for all is almost an implementation of the facade pattern in service context. It does not appear to be a good idea imho.

    In order to handle changes, use service versioning. See http://msdn.microsoft.com/en-us/library/ms731060(v=vs.110).aspx

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Wednesday, December 18, 2013 6:29 AM