Is there such a thing as too many WCF services? [closed]

Question

I have a bit of a problem, and I'm not really sure how to tackle it. I have my model assembly which contains about 200 different business objects (Order, Customer, Product, etc.).

I don't want to return an entire object graph when someone wants to get, for example, an Order. Instead I want to simply return the object and lazy-load (or even asynchronously load) the other parts. This seems like it's going to lead to a lot of "Get(Object Name)" services:

• GetOrder(int id)
• GetCustomer(int id)
• GetProduct(int id)
• etc.

I don't want to create 200 different methods, one for each Get operation. I realize I could probably do something like: GetObject(string type, int id), and then use reflection somehow to get the appropriate object back, but I think that is even worse (possibly).

If I, instead, used T4 templates to automate the job of creating each of the different services, that would be better... but it still leaves me worrying about one thing... performance.

Is it bad to have 200+ different services being exposed (one for each object)?

Answer 1

From my experience, WCF + Entity Framework + Lazy loading + deep object graphs + performance requirements = big potential problems.

There is no amazing silver bullet that solves all problems, I ended up with the following:

• lazy loading disabled. I think lazy loading just creates more problems that is solves: performance issues if not used properly, difficulty to catch exceptions (as a SQL request could be executed at any time, not just on that line of code that initially fetches the root entity from the DB)
• T4 template modified, so the setter of navigation properties is now private. No more collection of objects automatically serialized to the client side
• eager loaded object graphs sent to the client through WCF, as well as custom POCO (in case you want to fetch multiple entities in a single WCF call).
• No generic repository pattern. The client just calls some GetXXXX/GetXXXByYYY methods. And even GetXXXByYYYWithZZZZWithWWWW where ZZZZ and WWWW are names of eager loaded properties. Yes, there could be lots of methods, but you build them only when actually needed by the client side of the application, and you know what you are doing. This greatly helps to have good performances.

Is it bad to have 200+ different services being exposed (one for each object)?

Those are 200+ different operations in a single service (I suppose). If your client actually needs to access to all your server-side entities, then yes, 200+ operations is OK, there is just no magic here.