This post:
http://forums.lhotka.net/forums/t/9430.aspx
Ended up with a short discussion about some projected changes to the DataPortal. While this question doesn't directly pertain to that, it did raise another question in my head. So rather than divert the original post even further, I figured I'd start a new one.
What's the possibility of essentially segregating the DataPortal out into a standalone assembly in a future version of CSLA? It's been mentioned a couple of times that the DataPortal doesn't really have any dependency on CSLA objects - any serializable object can move through the DataPortal.
The reason I ask is that we're starting to get into SL development, and while I don't think I could convince folks to use the full CSLA, I very well could convince them to use the DataPortal as our transport mechanism between client and server. I think that would be a real boon to our development, and would save us a whole bunch of time that would essentially be spent "re-inventing the wheel". So being able to grab that piece in its entirety easily would be beneficial.
I'm sure some folks would say that if I can convince them of using the DataPortal, moving to the full CSLA isn't that far behind. From my perspective, that's not necessarily the case. Using the DataPortal could be considered a "black box" that doesn't significantly impact the programming model, while moving full-force to CSLA objects is a much more... well, intrusive change.
(And yes, while I realize that anything we do build in-house is likely going to replicate a fair amount of the CSLA codebase, we already have some developers who do not share my views on the value of the CSLA structure for business objects. One fight at a time...)
- Scott
First, the following is speculation - I really don't think I'll ever do this. My recommendation is at the bottom.
But consider.
The data portal depends on code in Csla.Core, Csla.Serialization, Csla.Reflection and (I think) Csla.Threading.
So all those would need to move into this new project.
Of course other parts of Csla have dependencies on those namespaces/features as well.
But you can argue that none of them have anything to do with the data portal - it is just that the data portal depends on them.
So following this train of thought to its logical conclusion, someone might say "I want to use the cool dynamic method features from Csla.Reflection, and I don't want to use the rest of CSLA".
To accommodate that, I'd really need to move those things into a Csla.Core.dll, or maybe Csla.Core.dll, Csla.Serialization.dll, Csla.Reflection.dll, etc.
Then a normal CSLA user would need to (at a minimum) add references to maybe 4-6 assemblies.
If we took a vote on that, I'm pretty sure we can predict the (overwhelming) outcome.
I still remember the rejoicing that occurred when CSLA 2.0 had just one assembly (as opposed to the five or so from 1.x)
My recommendation to you Scott, is to reference Csla.dll and only use the data portal. Just ignore the rest of what's in the assembly.
(though on Silverlight and WP7 you would need to make use of the various IMobileObject base types: MobileObject, MobileList, etc. to build serializable objects)
Copyright (c) Marimer LLC