Question

I am currently developing an application which by design has a three-tier architecture. It is composed of an administration website, a WCF webservice and a database. Of course, the website doesn’t directly connect to the database, so that all requests and responses must pass through the service. The “problem” is that there are several entities involved in this application, and for each one of them I must support the basic CRUD operations and many more, which makes the service have right now more than 30 methods in a single endpoint. Since I already had to increase the maximum message size, I begin to ask myself if having all those methods in a single service is not too much. What do you think? What alternatives do I have?

Answer 1

I can’t really give you a good answer since it kind of depends on the requirements and complexity of your application. Typically a CRUDy service interface is an antipattern you should avoid. There shouldn’t be a one-to-one mappings between your data layer and your service layer. If there is then the service layer is kind of not pulling it’s own weight. SOA is a huge topic that I’m only starting to get my head around but my understanding is that SOA’s are supposed to encapsulate the logic of many operations. Ie (Authentication, Authorization, Logging, Scaling, Transactions, etc.)

http://msdn.microsoft.com/en-us/library/ms954638.aspx

Have you heard of the Repository pattern? That’s a software design pattern where a particular class/assembly encapsulates the logic required for getting data into and out of the database. It’s lighter weight then using full blown services and might be all you need if what you want is a good way of decoupling your application from the database. A really neat feature of the Repository pattern is that you can make all the methods of the Repository an Interface and then make a MockImplementation to perform testing on your business/UI layers independently of your database.

http://msdn.microsoft.com/en-us/library/ff649690.aspx