Best asp.net WCF application design

Question

I am working with a financial application and am looking for the best solution for designing my application.

We have 100's of stored procedures where most/all of our business logic sits. We have WCF web services projects built using Web Service Software Factory (http://servicefactory.codeplex.com/). We have stored procedures built for nearly everything (tables, dropdowns, etc..) and each of these stored procs have their own webservice exposed to be called by the web application. Each web service is a very simple method that calls the stored procedure with the exact paramaters of the web service.

I am not too sure if this is the best design and would like to ask for suggestions and alternatives to the design.

Does anyone else have a similar environment ? How is it implemented on your end ?

Answer 1

It's a classic trade-off between:

• having small, focused services that do one thing and one thing only - you end up with lots of 'em
• having larger services with lots of methods that do lots of things - but you have fewer of them

In general, I would say I would prefer approach #1 - keep your services nice and small and easy to maintain, and respect the single responsibility principle - a service (or class) should do one thing and one thing only.

You might be able to combine a few calls that logically belong together into a single service with a few calls - but as soon as the service has too many calls (more than 10? 15? 20?) it has a tendency to get unwieldy and you end up having to change it too frequently because it handles so many tasks....

Answer 2

My take is based on what is intended use of services - are they going to server external applications or meant for consumption within your application only?

For within-application usage, I tend to go with an in-process chatty layer rather than having an out of process tier (for example, services layer doing CRUD tasks etc). Former are very good from performance perspective and scaling can be still possible by using multiple web servers etc. The same in-process layer can be hosted with multiple fronts - for example a Web app used for Application UI, Console App doing daily job, WCF services consumed by third party etc. Transaction management and flowing contextual information can be simple in in-process layer - although its possible with WCF Services layer - its very expensive.

For external consumers, WCF services are great front but then service interface should be chunky and must expose functionality strictly from business terms (for example, it should not have CRUD methods that are meant for persistence but rather methods that make sense from domain - say CreateOrder that would create entries into multiple tables).