I know, there have been very similar posts some years ago, but I think at least two things have changed: The unit-of-work principle has beome prominent, and we now have an object factory option.
The scenario is basically that of post "Multiple modules with each there own businessobjects".
You may have common business objects. Then you have one module, which is about product and orders.
Another module is responsible for accounting and budeting.
I would guess, that "accounting and budgeting" should be separated; it could be replaced by a commercial product. From this perspective, I'd prefer to design two separate VisualStudio project for the business layer.
On the other hand, user want screens combining information of both modules. Additionally for better experience, they also want to create and update data from both modules. Taking these needs into account, it would be probably simpler (and better?) to have only one VisualStudio project.
Or should we work with two modules, plus a third on top of both, which contains the unit-of-work and commands to support the combining?
In general, I prefer simple project set-ups. The downside however is, that developer don't have structures enforced and begin to cross-link almost every object with each another ... not that bad actually ;-)
What do you think?
In my opinion there is no one single answer to this. So much depend on the context within which you operate.
However, as a simple rule if you find your business objects being used by multiple applications (as opposed to a single large application) I'd probably advise you go for separate assemblies and structure these to be very domain oriented. Of course I would always extract framework or commonality into separate core assemblies for general reuse. The real kicker for me has always been that knowledge of the domain – depending on the environment you work in it can be very understood or very not understood. Personally I learn something new about the environment I am currently working in every day so making a call on what domain classes to include in what assemblies is not trivial.
The good thing is that any single UI can easily reference multiple assemblies (just like you do already with .net) to achieve some business needs. It might be simpler to reference one but on the scale of how important that is it’d score very low in my mind (your developers are very intelligent people!!). I would like the designers/IDE to suggest inclusion of related/associated DLLs when you include a 1st that references a 2nd though (to my knowledge VS2010 doesn’t do this).
I don’t see any argument for combining all your classes into one DLL being inherently better though. And, of course, you can still do this with the linker if needs me.
Simplicity is good, I understand that, but if you find your client is downloading a 50MB dll for a one screen application you know you're not doing the best you can for him/her. And I think the days of the big all encompassing system are behind us. We’re in the days of the small targeted component/feature/satellite app that plays a part in an overall suite called The Product or System. If I’m responsible for updating our product catalogue I don’t want any order entry screens embedded in my .exe. However, if its xmas eve and all hands as required to fill orders I might be granted order entry privileges at which point I will need those components downloaded to my workstation.
I would probably also encourage you to separate your UoW classes into separate assemblies especially if they really are only glorified presentation objects (referencing and delegating). It a personal (and probably not popular) opinion but I see pure presentation-type UoWs as not belonging in the pure business layer.
Hope all that makes some sense!
Thanks for your response.
The first paragraph is my dilemma: There are a few people who are familiar with design (data and OO), and the expert of the domain and experts of an existing application from the 90's. No moving to new technology, we also want to overcome some limitation and improve maintainability. Experts of both domains have to learn and convince the others. And it's a very constructive process.
There's no problem in finding and reference an assembly. But thinking a designing in a networked fashion always ends in cyclic dependencies.
And I'll specially remember your last point ("presentation objects").
It seems that layering horizontally is way easier than separate vertically (maybe, it's because we look at things in a networked manner).
It is often challenging to achieve vertical business separation. The primary reason for doing this isn't usually technical, it is business related.
Several times I have worked on products that were sold or enabled by module. The user either didn't buy certain modules, or users weren't authorized to use certain modules. So the applications were designed with very clear module separation, because the module might not be available at runtime.
There was stil inter-module navitation, but that was purely at the UI level, and the appropriate links or menu options were disabled based on module availability for each user. At no point were objects within one module allowed to interact with objects or types in another module.
I think there's limited value here from a technical perspective, especialy given the cost/complexity. But the business value can be quite high if you have requirements like those I'm describing.
Thanks a lot for your answers (also from "Use of ManageObjectLifetime in project tracker example").
Right! Often you want to avoid coupling (and then also turn reuse down, because coupling is the worse).
My goal of having multiple assemblies is very similar: I want to reduce thight coupling all over the business objects. The idea is to find subsets (clusters) of BOs, where coherence is high and coupling is OK. However, between the subsets there should be a degree of separation.
And I was wondering why I haven't found examples, code generators, etc. that use / produce code for multiple assemblies? Maybe because desinging this way is too hard.
Copyright (c) Marimer LLC