WCF/Client apps - where should business logic go?

Question

Hi

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? Thanks a lot for the help.

Cheers Mark

Answer 1

I think what is "correct" depends on your application architecture. There is certainly value in separation of concerns. It sounds like your boss feels that the current model is to use the server as a data access layer that maps the database to business objects and that business logic should be implemented on the client.

You can still have separation of concerns whether the business logic is implemented on the client or the server. It's not where you do the processing that counts, but how cleanly you have designed the interfaces between the tiers of the application.

It might help to know more about the client. Are you dealing with a browser/Javascript client? If so then I'd keep as much processing as possible on the server and send data to the client more or less in the form that you want it displayed.

If it's a C# client then you have a lot more power to work with on that end. You could probably reconstitute the WCF service's responses into the same business object classes you were using on the server side and get the same power that you had on the server. (Just share the business object classes between the two solutions.)

Answer 2

There is no hard and fast rule for this, but in this case i would say that your boss is more wrong than you :) Everyone will have a slightly different opinion on this, and there can be a number of reasons why your business logic is put in places other than the business layer, but there is seldom a reason to put it in the client app - you could argue that when it is in the client app then it is a UI or presentation rule rather than a business rule.

If the webservices are going to be used by a number of applications, then as much as possible you want the business logic on the webservice side. I would actually have a very thin webservice layer, all it does is accept the call and then pass execution on to the actual business layer. I would also have the mapping between database data and business data entities done in the database layer, not the business layer.

Answer 3

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.