none
WCF service as Business tier RRS feed

  • Question

  • Hi,

    I'm designing an application with WPF client. The client connect to the server using WCF. I can think of few options in regards to the relationships between the WCF service and the business tier:

    1. Have the business logic implemented inside the service assembly so the service recieve calls from the client and process them.
    2. Have the busines tier in a different assembly which will be referenced by the service. All the service does is transfer the calls to the business tier.
    3. Have the busines tier in a different assembly which in itself become a WCF service making the original service its client.

    I can see the benefit of the third one for scalability purposes. However this is not relevant for the above application. I'm wondering if there are certain benefits for using option 2 over option 1?

    Thank you,

    Ken

    Friday, December 12, 2008 5:35 AM

Answers

  • Hi,

    I see the main advantage of 2 over 1 in feeing up your business logic from dependency on particular technology, WCF in your case. Threoreticaly you can use WCF service implementation in a non-WCF context, but i found it a 'dirty' solution. You have all the WCF-specific attributes and serializable datatypes. Having service implementation and business logic in two separate assemblies is also good in sence of Separation-of-Concernts principle. Your business logic class have only business responsibilities. Your service impl class have only communication-related responsibilities. 

    Threre is also a technical issue. Best practices of WCF suggest using single-call instance mode because it is most efficient.Singleton mode automaticaly synchronizes all operations so you end with one-request-at-a-time solution which definitly is wrong. When you separate service impl from business you can define business logic class as a singleton and use service in single-call mode. In such case on service impl instance is instantiated per call, but each of them forwards requests to sole instance of business logic. To be honest this scenario is also possible using custom instance provider for WCF, but my point is it is that separating servic impl from business logic looses coupling and provides you with additional possibilities at virtually no cost at all.

    Hope that helps

    Szymon
    Friday, December 12, 2008 6:50 AM
  • As Szymon has mentioned, I agree the same.  Option 2 is your best bet.  Actually I dont understand the description for option 3, still I would say option 2 is certainly scalable solution.  I have published a reference application architecture using .NET 3.5 at http://gajakannan.com/netarch.aspx.  Take a look at it.  It may help you on your quest.

     

    { Gaja; }

     

    Friday, December 12, 2008 7:05 AM
  •  

     KenSaraf wrote:

    Have the business logic implemented inside the service assembly so the service recieve calls from the client and process them.

    You would end up tightly coupling the communication infrastructure to the business logic. If at a later point in time any of your internal client apps want to connect to BL, it would not be possible. However, if you are sure that nobody else would want to use this BL then you can use this. But this wouldn't be a best practice.

     

     KenSaraf wrote:

    Have the busines tier in a different assembly which will be referenced by the service. All the service does is transfer the calls to the business tier.

    This would be right. This way your BL assembly is re-usable and not tightly coupled with the service. However, the two dlls (SL and BL) have to be on the same m/c (coupling from deployment perspective). Else you will have new constraints to consider (like how to invoke the BL dll).

     

     KenSaraf wrote:

    Have the busines tier in a different assembly which in itself become a WCF service making the original service its client.

    I don't see any reason why you would want to create an extra wrapper here. This option is same as 1 with an extra WCF wrapper. This doesnt seem to be the right approach considering the information that you have provided.

     

    Hope this helps

     

    --Pavan

    Friday, December 12, 2008 2:10 PM

All replies

  • Hi,

    I see the main advantage of 2 over 1 in feeing up your business logic from dependency on particular technology, WCF in your case. Threoreticaly you can use WCF service implementation in a non-WCF context, but i found it a 'dirty' solution. You have all the WCF-specific attributes and serializable datatypes. Having service implementation and business logic in two separate assemblies is also good in sence of Separation-of-Concernts principle. Your business logic class have only business responsibilities. Your service impl class have only communication-related responsibilities. 

    Threre is also a technical issue. Best practices of WCF suggest using single-call instance mode because it is most efficient.Singleton mode automaticaly synchronizes all operations so you end with one-request-at-a-time solution which definitly is wrong. When you separate service impl from business you can define business logic class as a singleton and use service in single-call mode. In such case on service impl instance is instantiated per call, but each of them forwards requests to sole instance of business logic. To be honest this scenario is also possible using custom instance provider for WCF, but my point is it is that separating servic impl from business logic looses coupling and provides you with additional possibilities at virtually no cost at all.

    Hope that helps

    Szymon
    Friday, December 12, 2008 6:50 AM
  • As Szymon has mentioned, I agree the same.  Option 2 is your best bet.  Actually I dont understand the description for option 3, still I would say option 2 is certainly scalable solution.  I have published a reference application architecture using .NET 3.5 at http://gajakannan.com/netarch.aspx.  Take a look at it.  It may help you on your quest.

     

    { Gaja; }

     

    Friday, December 12, 2008 7:05 AM
  •  

     KenSaraf wrote:

    Have the business logic implemented inside the service assembly so the service recieve calls from the client and process them.

    You would end up tightly coupling the communication infrastructure to the business logic. If at a later point in time any of your internal client apps want to connect to BL, it would not be possible. However, if you are sure that nobody else would want to use this BL then you can use this. But this wouldn't be a best practice.

     

     KenSaraf wrote:

    Have the busines tier in a different assembly which will be referenced by the service. All the service does is transfer the calls to the business tier.

    This would be right. This way your BL assembly is re-usable and not tightly coupled with the service. However, the two dlls (SL and BL) have to be on the same m/c (coupling from deployment perspective). Else you will have new constraints to consider (like how to invoke the BL dll).

     

     KenSaraf wrote:

    Have the busines tier in a different assembly which in itself become a WCF service making the original service its client.

    I don't see any reason why you would want to create an extra wrapper here. This option is same as 1 with an extra WCF wrapper. This doesnt seem to be the right approach considering the information that you have provided.

     

    Hope this helps

     

    --Pavan

    Friday, December 12, 2008 2:10 PM
  • Thank you all Smile

    I see the decoupling point clearly now and I wasn't aware of the WCF as singlton issue.

    Thank you,

    Ken

     

    Friday, December 12, 2008 7:03 PM
  • If you put business logic in domain entities, you have to create data contracts seperately from business entities. I don't know how the above three people dealt with the seperation between data contracts and business entities

    Tuesday, December 23, 2008 8:21 PM
  • Hi Yale,

    I actually never mix my business process classes with my business entities. After much thought I decided to use the EF entities as my business entities (which are given a dataMember attributes automatically). While they are not "pure" POCO I still thought it will save me a lot of work and I can always utilize the fact that they are partial classes. I keep the EF entities in a seperate assembly and while it's true that my Business Process classes reference this assembly, I keep the CRUD operation strictly to my DAL classes. I found a more "pure" approach here:

    http://msdn.microsoft.com/en-us/magazine/dd263098.aspx but personally I think the overhead is not justified.

    I hope that clarify some points,

    Thank you,

    Ken

     

    Monday, December 29, 2008 9:06 PM
  • Hi all,

    I have a quite similar situation but i can't figure out is it any tool or any good practise to do customization WCF services or even business layer and EDMX.
    Our situation is something like
    GUI layer --> WCF services --> Business layer --> Data layer (EDMX)
    (1 gui.dll) --> (                        WCF servces dll                                   )


    We may have a possibilities to allow user customize from GUI,  add new WCF services, add business layer or even add a new table in our database). I wonder how we should do to attach on the original  development (core dev) but not affect the core coding).

    1 more thing is about ""WCF LOB Adapter", is this suitable for us apply in our situation between the GUI and WCF services.


    I really need your guys help urgently. Thanks a lot.


    NO
    Friday, February 13, 2009 1:35 AM