Layered development with Service Factory

Topics: General Discussion Forum, Service Factory Modeling Edition Forum
Jun 4, 2008 at 5:17 PM
I have a very big product that has many C++ and C# projects. So we are continuously moving towards cleaner layered design/development.

So, we eneded up with:
          - DAL solution/projects, 
          - Common Service/Business Logic solution/Projects
          - Service Factory solution [That exposes Service contracts and Data contracts] and related stuff
          - UI projects solution

Now, if I truely go by what is recommened by Service Factory documentation, I will end up doing following:
          - Load/Save Business entities in DAL layer  
          - Translate BE (Business Entities) to DC (Data contracts) in Service Factory projects
          - Expose only Service/Data contracts to end clients and UI.

But in practice I am not able to get over few concepts and concerns. I am hoping to get some guidance from experts who worked and aware of these scenarios

My concerns/confusion/approach: (Please provide your input on following)
          - We have too many service interfaces that we need to migrate to WCF type service contracts [Is this best OR should we look for any consolidation]
          - Translating Business entity to Data contract -seems technically right but most of the time our Data contract is very similar to business entity [Are we loosing performance in translation?]
          - Re-use of other services: As per WCF/Service oriented tenets- services are autonomous. But when I am already on server-side, if I need to re-use different service, I prefer to go directly 
            than forcing WCF call. [Currently we do this by ONLY linking to actual service interface and get some Factory class create actual type (through reflection) and return us interface
          - This approach seems like best from performance point of view when re-using services on server-side - we are still going by interface/contract rules. But we are not callling them through.
          - Our existing client uses DataSets heavily as our we have Smart Client and heavily use 3rd party grids [that work well with type DataSets]. 
          - Now if we create new DataContracts through Service Factory - we will end up with custom entities.
                 - Either we should change our UI to use custom entities and support custom binding (Which we might mostly force ourself to do for new UI)
                 - OR we still use Type DataSets on UI (Like UI Entities) and do another translation in UI layer [causing more delay?]

General Service Factory questions:
     - I like Service Factory and productivity it is giving us. But is there a way to break this service factory to multiple parts:
             - I want to do just Data Contracts in one solution
             - Just Service Contracts in other solution [Re-using DataContracts created above in different solution]
             - Do hosting stuff in separate solution.

Although there are exellent labs and documentation on how to customize it I never got my hands around customizing Service Factory guidance package. I am also concerned about what happens when we move to VS 2008 (Currently on 2005) and would prefer to get latest version of SF guidance package. What will happen if I have customized my old guidance package.

I would really appreciate any expect in WCF/SF world who worked and used SF/WCF on large projects to shed some light and share their experience/thoughts.

I also want to know what are best recommended tools to test performance on WCF/SF based implementation.

Regards
RJ
Developer
Jun 10, 2008 at 2:57 PM

Hi RJ, inline you will find the answers to your questions.

Thanks



RJ wrote:
I have a very big product that has many C++ and C# projects. So we are continuously moving towards cleaner layered design/development.

So, we eneded up with:
          - DAL solution/projects, 
          - Common Service/Business Logic solution/Projects
          - Service Factory solution [That exposes Service contracts and Data contracts] and related stuff
          - UI projects solution

Now, if I truely go by what is recommened by Service Factory documentation, I will end up doing following:
          - Load/Save Business entities in DAL layer  
          - Translate BE (Business Entities) to DC (Data contracts) in Service Factory projects
          - Expose only Service/Data contracts to end clients and UI.

But in practice I am not able to get over few concepts and concerns. I am hoping to get some guidance from experts who worked and aware of these scenarios

My concerns/confusion/approach: (Please provide your input on following)
          - We have too many service interfaces that we need to migrate to WCF type service contracts [Is this best OR should we look for any consolidation] 

Consolidation would depend on your technology requirements, the service model is not a limitation in this sense.  However, consolidating contracts (if applicable) will give some advantages like less modeling and maintenance workload along with a simpler design (ideally). On the other hand, you should consider in your design, how you will map your service contracts to your service implementations, because WSSF will allow a 1:1 mapping or you may change the built in behavior but it may take some work, as described here: http://www.codeplex.com/servicefactory/Thread/View.aspx?ThreadId=17736  . Other post regarding this; http://www.codeplex.com/servicefactory/Thread/View.aspx?ThreadId=22838

          - Translating Business entity to Data contract -seems technically right but most of the time our Data contract is very similar to business entity [Are we loosing performance in translation?] 
Performance would be almost the same. It would be a one on one property mapping, so it won’t be such a significant loss. Nevertheless, having a separation between your Data Contract types and your BE types will give you a more “service oriented” design. Further reading regarding Message Contracts and Data Contracts: http://blogs.msdn.com/donsmith/archive/2008/03/10/using-messagecontracts-and-datacontracts.aspx

          - Re-use of other services: As per WCF/Service oriented tenets- services are autonomous. But when I am already on server-side, if I need to re-use different service, I prefer to go directly 
            than forcing WCF call. [Currently we do this by ONLY linking to actual service interface and get some Factory class create actual type (through reflection) and return us interface
          - This approach seems like best from performance point of view when re-using services on server-side - we are still going by interface/contract rules. But we are not callling them through.
          - Our existing client uses DataSets heavily as our we have Smart Client and heavily use 3rd party grids [that work well with type DataSets]. 
          - Now if we create new DataContracts through Service Factory - we will end up with custom entities.
                 - Either we should change our UI to use custom entities and support custom binding (Which we might mostly force ourself to do for new UI)
                 - OR we still use Type DataSets on UI (Like UI Entities) and do another translation in UI layer [causing more delay?]

The first approach seems more WCF oriented, it may represent an overhead to modify the UI to be in line with the brand new entities but any future changes would be much  more straight forward later on. Also, consider that you will also have the benefit of working with type safe objects which provide you intellisense and most importantly, compile time validation. Further readings: http://www.hanselman.com/blog/PermaLink,guid,d88f7539-10d8-4697-8c6e-1badb08bb3f5.aspx

General Service Factory questions:
     - I like Service Factory and productivity it is giving us. But is there a way to break this service factory to multiple parts:
             - I want to do just Data Contracts in one solution
             - Just Service Contracts in other solution [Re-using DataContracts created above in different solution]
             - Do hosting stuff in separate solution.

This is possible, you should use the same base model for all the different solutions. The mapping table would be the same but you will basically be pointing to different physical locations when generating the code based on the different models.


Although there are exellent labs and documentation on how to customize it I never got my hands around customizing Service Factory guidance package. I am also concerned about what happens when we move to VS 2008 (Currently on 2005) and would prefer to get latest version of SF guidance package. What will happen if I have customized my old guidance package.

As you mentioned, the labs and docs will provide some guidance on how to “adapt” the WSSF: Modeling Edition to your needs (and customize it).

Here you have some posts regarding the conversion and migration of projects with the previous version of WSSF:

http://www.codeplex.com/servicefactory/Thread/View.aspx?ThreadId=20672

http://www.codeplex.com/servicefactory/Thread/View.aspx?ThreadId=17597



I would really appreciate any expect in WCF/SF world who worked and used SF/WCF on large projects to shed some light and share their experience/thoughts.

I also want to know what are best recommended tools to test performance on WCF/SF based implementation.

Regards
RJ