Is there any case to be made for building your Silverlight apps using an SOA architecture where CSLA is used to build the service and CSLA is also used between the service and the silverlight app? I know that sounds like an overly complex solution but is there ever a need to build your system that way? (Assuming you have complete control over how the system is built)
If I understand your question, the answer is absolutely.
The idea behind CSLA is that you will have a completely re-usable business layer. This means that it can be used directly from some UI tech (I.E. silverlight, wpf, winforms, etc.) or it can be consumed by an edge application via a service. If you have created your BOs correctly, then there should be little to no effort exposing your CSLA objects through a service as well as consuming them directly from a UI.
I know you can use CSLA to create web services pretty easily.
My question is that if you are developing a system using CSLA and you are completely in control of both the client side and the server side, does it ever make sense to build on the server side (using CSLA) web services to be used to connect to your client (also built using CSLA). At first glance, this seems to be overkill, but my question is does this architecture ever make sense to use? Is there a case to be made to build your systems in this way?
Normally, I think of a CSLA system as layered like this: (UI on client being a Silverlight App)
UI on client/CSLA on client/CSLA on server/DB
What I am asking is does it ever make sense to layer your system like this:
UI on client/CSLA on client/CSLA on server/web service based on CSLA on server/DB
or like this:
UI on client/CSLA on client/web service based on CSLA on server/DB
I hope that is a little clearer.
I see what you are saying...
I guess there is a little value in forcing your client to go through your web service. It will go a long way to ensuring that your business objects are designed in such a way that they can be consumed from a web service by an edge application. however, it isn't 100% assurance since the possibility exists that your client side CSLA layer may have logic that is inadvertently needed in order for the web service to function (which in my mind would be a design flaw).
One drawback I see is that you are no longer using the DataPortal as your comunication mechanism and your application context will not be serialized (unless you provide a way to do that)...
So I guess I see some value in that architecture, but not much.
I also didn't see much need to go this route either ... I was just wondering if I was overlooking something before abandoning it as a possibility.
The reason I even was thinking about it is due to how Silverlight is presented to most developers as a way to create an App that works in an SOA world. But in reality, CSLA Silverlight apps are working in an n-tier client/server model and not in an SOA model.
I think that should be emphasized when starting to working with Silverlight and CSLA. I know it took me some time to realize that as I was coming from the SOA world and thinking that SOA was the CSLA model for working with Silverlight.
I hope other newcomers to Silverlight and CSLA will benefit from reading our exchange on this.
Copyright (c) Marimer LLC