8

I am unsure where to place my business logic. I have a WCF service which exposes its methods to my client.

Should my business logic go in the service method

public User GetUser(int id)
{  
     //Retrieve the user from a repository and perform business logic
     return user;
}

or should it be in a separate class where each WCF service method will in turn call the business layer methods.

public User GetUser(int id)
{  
     return _userLogic.GetUser(id);
}
ministrymason
  • 1,783
  • 2
  • 20
  • 33

5 Answers5

8

My personal preference is to have WCF as a very thin layer on top of a separate business layer. The WCF layer does nothing more than make calls to the business layer, similar to what you have shown in option 2. This gives you some flexibility in the event that you want to have your business layer consumed by something other than WCF clients (for example, a WPF application calling your business layer directly rather than via WCF).

chris.house.00
  • 3,273
  • 1
  • 27
  • 36
  • 2
    I have to agree. I treat the WCF class as a communication mechanism, nothing more, and business logic doesn't belong there. – Eric King Dec 05 '11 at 22:36
2

WCF services are already, by default, designed for reuse. I see no reason not to have some logic in your services, though keep in mind things like the Single Responsibility Principle so you don't end up with a service that does a dozen things.

Even then, if you end up parceling out your functionality into smaller classes, it's not a bad idea at all to host those classes as WCF services. You can then use them in-proc (via pipes) when needed or across machine boundaries (tcp) or even as web services. Create facades as needed to provide access to the functionality of your other, smaller services.

There's no real need to avoid putting any logic in WCF service classes.

Tad Donaghe
  • 6,625
  • 1
  • 29
  • 64
  • Disagree strongly, but since nothing you have said is technically wrong, I'm not going to down vote. – Maess Dec 05 '11 at 16:54
  • Why do you disagree? I have created my services like example two. But they don't look correct, because all they are doing is calling the corresponding method in my business logic layer. Seems like code that isn't necessary. – ministrymason Dec 05 '11 at 16:57
  • 1
    Services are, essentially, a way of exposing functionality and presenting data, basically a presentation layer minus the GUI. Having business logic in your WCF layer binds that logic directly to the service. If later, you add another application that also needs the logic behind 'user' you are have painted yourself into the corner of needing to bind it to your service rather than reusing that part the the BL. – Maess Dec 05 '11 at 17:03
  • I'm not sure I understand, Maess. If I have logic that I'm exposing as a service, then I want to share it with as many clients as possible. If I find that my service is too tightly coupled with a particular client, that's a problem with the design of the service, not due to WCF. Designed properly, my service should be able to handle many different clients in different situations. – Tad Donaghe Dec 05 '11 at 17:06
  • What if my new client doesn't want or need the overhead involved with calling a service? You have painted yourself into a corner where you must either later move the logic to a BL or you force the unnecessary use of the service. Also, you don't want to describe your core domain directly in the service as a domain will encompass more than one service. – Maess Dec 05 '11 at 17:10
  • If you call the service in process via named pipes there's not enough of an overhead to grumble about, or at least not that I can see. – Tad Donaghe Dec 05 '11 at 17:12
  • 2
    @Maess, Just because a class is a service doesn't stop it from being a class. You could always ignore the WCF part and call the code as normal method, with no overhead. – Buh Buh Dec 05 '11 at 17:43
2

I think that the decision depends on your business needs. WCF is a mechanism to transport data (objects) between server and client. If you like your businsess logic runs on server, you should let WCF exposes the object after running your business logic.

hshen
  • 468
  • 1
  • 4
  • 13
1

It should go in a separate set of classes. Your WCF layer should only contain logic that directly pertains to how the product of the service is delivered.

In your case, I see that you have a WCF method that returns a User (I assume this is a custom class) why have a separate method to return the UserID instead of populating that property as part of returning the User object?

Maess
  • 4,118
  • 20
  • 29
0

For reuse/testability/maintenance/readability you should always put you BL in a separate layer.

Peter
  • 27,590
  • 8
  • 64
  • 84
  • so should my service do nothing apart from call the method in the business logic layer. Like example two? – ministrymason Dec 05 '11 at 16:53
  • Normally there will be more logic in the BusinessLogic layer then just a get function. If your sample is your whole class, you should use method 1, if not and you do have multiple services. Do some extra work now and build a BusinessLayer. In the future, reuse/testability/maintenance/readability will be far better then in long methods in the service layer. Your goal should be to write logic only once. You will get closer to this goal by slitting service and business logic. – Peter Dec 05 '11 at 17:01
  • the method shown is just for clarity. My actual business logic methods contain complex linq queries and validation. I have implemented it as method two. All my services just call the corresponding business logic methods. I was just wondering if this is the best architecture. At the moment I have a web service, which calls the business logic layer, which in turn calls a repository which provides CRUD – ministrymason Dec 05 '11 at 17:07
  • Actually you are on the right track, one step further would be to move all CRUD to a DataLayer. This will make your businesslogic more readable. – Peter Dec 05 '11 at 17:12
  • You should keep with what you have now, just moving from a web service to WCF. – Maess Dec 05 '11 at 17:12