Better to put business logic in WCF Service or Code behind on Silverlight control?

720 views Asked by At

In trying to design an architecture for a Silverlight application, I am at a point in asking is it better to:

use an Entity Data Model with a WCF Data Service and then put my business logic in the code-behind for my silverlight user control to do any modifying/managing of pure data returned from WCF Data Service

or

use an Entity Data Model with a WCF Service and then put my business logic in the actual service using [OperationContract] methods in which I can apply my business logic in the service level thereby providing a clean seperation between presentation (silverlight) and business (service)

Can anybody provide their opinion on which approach would be better or if there is yet a better approach that I have not discovered outside the scope of my suggestions above?

Thanks

2

There are 2 answers

1
Reed Copsey On

I would, personally, use a combination of above (with modifications).

I would put the business logic and business rules, as appropriate, into your WCF service. This has many advantages, including allowing the service to do all of the data validation and checking (which it should, in any case), without requiring it to happen twice. This promotes reuse of your service for applications in the future, since the logic there is domain specific, and not tied to a specific presentation layer or application design.

That being said, I would not put logic specific to this application into the service. Instead, I would use an MVVM approach, and put the application-specific logic (separate from the business rules) into a ViewModel class, and use this from your Silverlight views. I would try to avoid using code-behind as a place to inject logic - whether application or business rule specific.

0
Shiv Kumar On

I wouldn't put the business logic in the actual service. The service is a Service Interface Layer

Essentially, it provides and interface (an API) between your "system" and the outside world. In this case your UI.

So you still need a business layer that has your logic. and the Service Interface layer talks to the business layer and surfaces the methods and data as a WCF Service.