WCF—How many methods are too much? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 9 years ago.

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

Answer 2

There is no real concrete answer to this question. It is a tradeoff either way. Try to keep the Single Responsibility Principle in mind. A couple options are to:

• Create an endpoint per data type, putting CRUD operations into each. That would mean maintaining more endpoint configuration through.
• Separate your methods into multiple files, but leave them in one class, using partial classes.
• If all you are doing is CRUD operations for each data type, then maybe use WCF Data Services / OData instead.

Answer 3

Implementing the repetitive CRUD functionality over the WCF service could be a pain but if the service is not exposed globally (so you don't have to pay a lot for the authentication/authorization) you can save a LOT of time by using one of the two: ADO.NET Data Services or WCF RIA Services.

Whether or not 30 methods on a single service is a bad design - this is not clear. It's like asking whether or not a class with 30 members is a bad design - some people will say that it definitely is, most will comment "it depends on what you are doing".

Nevertheless, using HTTP for CRUD brings some restrictions - one of which you mention. You will not be able to insert/update large batches unless you increase the message size. You can also have some serious issues with transaction handling unless you somehow involve the transactions over http in an explicit way.