CSLA.NET DataPortal being reused by multiple web/service applications?

CSLA.NET DataPortal being reused by multiple web/service applications?

Old forum URL: forums.lhotka.net/forums/t/8802.aspx

dsrini posted on Thursday, April 15, 2010


I am trying to catch up with CSLA framework since last few months. We are implementing the SL web portal based on the IssueTracker example, and buliding CSLA.Net objects for business use. I have come across few posts of how to configure remote WCF configurations and was wondering if these mobile objects for SL front end, can be reused (most of the code) for web services/windows service via remote data portal client configuration.

Thanks in advance.




RockfordLhotka replied on Thursday, April 15, 2010

You want to have a SL smart client, and also expose a service interface from a web server. And you want the SL clients and the web server to talk to your app server?

Yes, you can absolutely do this. Your app server needs to expose two endpoints, one for the SL data portal, and one for the .NET data portal. This just means you need two .svc files - one for each type of client.

Configure the SL .svc file like you have now, and configure the .NET .svc file as described in the Expert 2008 Business Objects book, or as it is done in any of the .NET sample apps.

dsrini replied on Friday, April 16, 2010

Hi Rocky,

As I read the forums and DataPortal definition in the book, It seems that DataPortal can service multiple applications such as SL clients or Windows services with one server end point, accessed via multiple client end points. I just wanted to confirm that we can indeed reuse the .Net Data Portal for multiple applications or services.

Thank you

RockfordLhotka replied on Friday, April 16, 2010


Yes, from a technical perspective you can use one server endpoint for multiple applications.

From a real-world perspective I don't think that's necessarily a great idea. The reason is that those applications will then share some information whether they like it or not. Specifically they'll share authorization/authentication models, the principals will have to share roles, they'll share the same data portal pipeline for things like IAuthorizeDataPortal, exception management and other data portal configuration. They'll also share Csla.ApplicationContext concepts.

Perhaps more importantly, the server would always have all assemblies for all applications all in the same environment. This means any application can interact with any other application's objects (on the server at least), because from the data portal's viewpoint this is all one big application.

I think you can make this work if you are careful, but this would allow some level of coupling between applications, and over time developers almost certainly would start making assumptions that might eventually make it impossible to separate the applications from each other

So technically the answer is yes, but you should think through the human/process/coupling aspects and decide if it is really a wise choice for you.

dsrini replied on Friday, April 16, 2010

Thank you.

Copyright (c) Marimer LLC