Print Page | Close Window

Hybrid architecture devforce

Printed From: IdeaBlade
Category: DevForce
Forum Name: DevForce 2010
Forum Discription: For .NET 4.0
URL: http://www.ideablade.com/forum/forum_posts.asp?TID=3176
Printed Date: 13-May-2026 at 3:08pm


Topic: Hybrid architecture devforce
Posted By: rbautistaole
Subject: Hybrid architecture devforce
Date Posted: 22-Dec-2011 at 7:59pm
Hi.
I have DevForce. After reading the article in http://msdn.microsoft.com/en-us/magazine/ee335715.aspx - http://msdn.microsoft.com/en-us/magazine/ee335715.aspx  i´m reflexive about the DevForce suggested architecture. I want to have a service layer that get the input (an entity) and coordinates a serie of domain objects to make one operation (May be many objects was updates some more inserted etc). With DevForce i think (may be wrong) that this service layer should be in the client side and then execute Context.Save.
I want to build an hybrid architecture where the read queries use DevForce with POCOS and the update queries use wcf services, the purpose to this is having the service layer server side (i know the server methods of devforce but i don´t like them). Can you gime some advice to this architecture?
thanks.


Replies:
Posted By: kimj
Date Posted: 23-Dec-2011 at 3:55pm
Which DevForce server methods don't you like?  Are you thinking the "remote server method" calls?   DevForce is structured to use what to EF are POCO types with WCF services used to query and save data, so DevForce is inherently n-tier.  Your link describes the extra steps required to make EF run n-tier, writing your own services, etc., none of which is required if you use DevForce.  The architecture section of the DRC ( http://drc.ideablade.com/xwiki/bin/view/Documentation/architecture - http://drc.ideablade.com/xwiki/bin/view/Documentation/architecture ) describes DevForce architecture in depth.

Posted By: rbautistaole
Date Posted: 23-Dec-2011 at 5:13pm
Thanks kimj.
Do you have a VS solution (server side, client side) as example to using server methods with ECS using Delegate?
thanks in advanced.

Posted By: kimj
Date Posted: 27-Dec-2011 at 1:48pm
Yes, here's a simple sample showing sending and receiving an ECS:  http://drc.ideablade.com/zip/Silverlight_RSM.zip - http://drc.ideablade.com/zip/Silverlight_RSM.zip

Posted By: rbautistaole
Date Posted: 27-Dec-2011 at 1:56pm
Well, with respect to the remote server methods, i don´t like that since althought the server methods can be encapsulated in some classes when are exposed to the client are grouped into the same EntityManager losting the granularity desired. In Adition seems not natural invoke a server method in such way
 var serverMethod = new ServerMethodDelegate(ServerMethods.GetNumberOfOrders);
 return (int)_entityManager.InvokeServerMethod(serverMethod, startDate, endDate);
since the client developer cannot discover the server method contracts.
 

 
 

Posted By: kimj
Date Posted: 27-Dec-2011 at 2:05pm
We agree that these methods are not ideal in their design, which is one reason why we consider them add-ons to the main DevForce functionality.
 
Although the methods are not discoverable and not strongly typed, you don't need to group the methods into a single EntityManager - they can be called from any EntityManager.  Most of our customers "hide" these methods from within repository methods, so that the calling code knows nothing about the actual invocation.

Posted By: rbautistaole
Date Posted: 27-Dec-2011 at 2:42pm
thanks Kim.
 
In your experience developing LOB APPS with devforce using "DevForce main funcionality" where place the business logic? in the client side or in the server side? i.e. I want to place the business logic in the RSM to avoid to deploy dlls to the client because in such case i should obfuscate that dlls moreover i should send more info through the net (because in the process logic i create new objects)
but i want to know your opinion.
 
thanks and excuse my bad english.
 

Posted By: kimj
Date Posted: 27-Dec-2011 at 4:44pm
You'd generally place most business logic server side, since you can secure the server.  This doesn't mean, though, that you must necessarily use RSM for your business logic.   You can write query and save interceptors to provide server-side query and save logic, use named queries, and provide server-side validation -- all without RSM.  Here's more information on server-side features:  http://drc.ideablade.com/xwiki/bin/view/Documentation/entityserver - http://drc.ideablade.com/xwiki/bin/view/Documentation/entityserver  .  I'd also encourage you to get in touch with our Professional Services group for more information on architecture and best practices.
 

Posted By: rbautistaole
Date Posted: 28-Dec-2011 at 8:45am

Ok, the option are the save interceptors. But place the business logic in the save interceptors break some basic principles of OOP IMHO. Well, i guess that í should to decide betwen save interceptors and RSM.

Time ago a feature request to saveinterceptor per class was placed
http://www.ideablade.com/forum/forum_posts.asp?TID=2603&title=where-to-place-business-rules - http://www.ideablade.com/forum/forum_posts.asp?TID=2603&title=where-to-place-business-rules
Do you have a timeline to implement this?
 
Do you have an application demo (VS solution in WPF) using save interceptors?
thanks.

Posted By: kimj
Date Posted: 28-Dec-2011 at 6:44pm
Regarding the feature request - I'm still checking on this.  It looks like this was displaced by other higher priority features and I don't know if it's currently on the roadmap.
 
We unfortunately don't have any real samples of using the save interceptor.  Several of the security samples use a simple save interceptor, but likely wouldn't help much.   At the moment the best example of a save interceptor is in the API documentation:  http://drc.ideablade.com/ApiDocumentation/webframe.html?IdeaBlade.EntityModel.Server~IdeaBlade.EntityModel.Server.EntityServerSaveInterceptor.html - http://drc.ideablade.com/ApiDocumentation/webframe.html?IdeaBlade.EntityModel.Server~IdeaBlade.EntityModel.Server.EntityServerSaveInterceptor.html
 


Print Page | Close Window