Let's say I am making a new system in a mostly Agile method.
I do not believe it actually matters towards my question, but let’s say I will be making a 3 tier system consisting of: Multiple Windows WPF applications with common CSLA object library (no DAL), a single Data Portal service to serve up said CSLA objects + a DAL (ObjectFactory based), some 3rd party database for persistence.
When I first start, all my objects, tests and applications will be very rudimentary; limited in properties and methods to only those required to get App1 off the ground. Then, soon after, App1 will start to get more detailed and App2, App3, etc. will get up and running. As this happens, my common business object library will be changing daily, and will most likely include additional properties on existing objects.
The questions is: How to deploy a new version of the Data Portal service in this environment?
Of course, I understand that I will eventually have to (want to) update the BO reference in every app, and that there are many ways to do this with source control and/or shared files, but none of those things will prevent App1 from existing somewhere with V1 of the business object library and the data portal serving up V2 of those same objects. And, I actually want to be able to run like this as my V2 objects are expected to be extensions of V1 (and if I make subtractive changes, I will have to do a complete reset of all apps) and so a V2 object might be usable in a V1 app (desired to be so anyways - I may have not thought that through enough).
I guess I want some way of bringing in a V2 serialization into a V1 object. In straight XML, this works fine because the V1 object can easily find all the V1 properties in a V2 data stream. Is there a way to address this in CSLA? Is there a way to "version" a BO's internal data storage such that you can tell if you have an object constructed from a V1 data stream or a V2 data stream?
Any response along these lines will be greatly appreciated. I tried searching the forum for this topic but could not find a keyword that produced my targeted result.
Oh, I forgot to mention that we are currently on CSLA 3.8.3.
Reuse causes coupling.
Reuse is a desirable concept - though a lot of people view it as a goal (which it is not - it is just a beneficial side-effect of good design).
Coupling is often described as the ultimate evil. It radically reduces maintainability and slows development to a crawl while reducing quality.
Unfortunately you can't easily get reuse without incurring coupling.
Given this backdrop, my consistent view for the past several years has been that objects should be designed for a specific use case. Not an application and certainly not an enterprise. Just a use case.
If, and only if, you can reuse an object without changing it should you consider applying that object to another use case in the same application. At no time should you try to reuse objects across applications (that is what messages and services are for).
If an object is mostly reusable, but you'd have to alter it to reuse it, then you can't directly reuse it - that would incur bad coupling. Obviously you don't want to duplicate code either (DRY), so you need to normalize the behavior of the object - creating a third object that contains the common behaviors. That technique is an important one, because it allows for reuse while minimizing (not eliminating) coupling.
I've discussed this numerous times on the forum and a little in the Expert 2008 Business Objects book.
This thread may be fun to read:
Copyright (c) Marimer LLC