WCF/Client apps - where should business logic go?
c#, design-patterns, wcf, wssf
Solution
My vote would be clear:
- put as much of the data integrity checks into the database
- put any other business logic checks into a business logic layer on the server side of the service
- put only simple checks like "field required" etc. into the client layer, optimally automatically determined from the database model or your business model
Why database? SQL in any shape or form has some very basic and very powerful check capabilities - make sure stuff is unique, make sure the relational integrity between tables is a given and so on - USE IT! If you do these checks in the database, then no matter how your user ultimately connects to your data (horror scenario: managers being able to connect directly to your tables with Excel to do some Business Intelligence work......), those checks will be in place and will be enforced. Enforcing data integrity is the utmost requirement in any system.
Why business logic on the server? Same reason the other answerers have mentioned: centralization. You do not want to have the business logic and your checks only in the client. What if some other department in your company or a third-party external consultant suddenly starts using your service, but all the validation and business checks aren't in place, since they don't know about them?? Not a good thing......
Logic in the client Yes, of course - you also want to put some simple checks into the client, especially if it's a web app. Things like "this field is required" or "max length for this field" etc. should be enforced as early as possible. Ideally, this will be automatically picked up by the clients from the database/service layer. ASP.NET server controls have client validation which can be automatically turned on, the Silverlight RIA Services can pick up data restriction in your backend data model and transport them to the client layer.
Problem
We're building a WCF Web Service using WSSF. The idea is that it will expose our main database via the service and allow us to build various applications and web sites on top of the service. At the moment I'm building a simple client app that will download some data from this service, manipulate it then give it to the user as a report CSV file. Now the question is where should the business logic (that manipulates the data) be located? I figured that I would put it inside the service. I already have a business layer in there with simple objects that map almost one to one with the database (customer, order etc). I figured that I would make some "higher level" objects to manipulate the data. For example by using the customer, order and other objects and producing a report etc. I thought the best place for this would be in the business layer for the service. In that way we could reuse this logic for various different applications if needed. Unfortunately my boss doesn't agree. He wants a "separation of concerns" and said that the correct place for this logic would be in a business layer inside the client app rather than in the service. I guess this could be simpler but I would like to use my powerful object model inside the service business layer to write this code. The objects exposed by the service are not "real" objects and are really just light weight data structures without the power of the full object model that exists inside the service business layer. What do you guys think?