We are going to have (like the subject already says) multiple modules with each there own businessobjects. But what if they are going to be reused? Ofcourse this is just something to show my problem, in the real world there are many many more of those relations.
Module: RelationshipManagement
Businessobject Customer and CustomerInfo
Module: ProductManagement
Businessobjects Product and ProductInfo
The Customer object has a managed property with ProductInfoList
The Product object wants a property with CustomerInfo.
And an circulair reference is ofcourse not allowed :)
For so far i see 2 solutions, of which one isn't going to keep consistency.
1) Create an interface module foreach module and reference interfaces instead of businessobjects
Will this work with CSLA?
2) Don't reuse businessobjects, but just copy-paste them.
No consistency.
We already did evaluation about it. It's not that one library might not work without the other. But it's more productivity of multiple people c.q. teams together while developing and maintainance later on. What we don't want is a very large assemblies with everything in it. We already have an common.dll with all generated dataentities in it, which is already very large. Our application has in total 1200 tabels.
Btw, common.dll with dataentities acting as businessentities :) which is why im are investigating if CSLA will be usefull.
I still have doubts since our business can be very very complex. As making software for almost every assurance company in our country, they need to prolongate monthly. Keeping track of history on assurances versions etc. oh my god i don't even want to think about rebuilding that part :)
I manage several large team projects and understand where you are coming from. However, I have a different perspective on breaking apart assemblies. I agree that it is way too cumbersome to put everything into a single assembly but I prefer the smallest number possible to accomplish the requirements.
The first questions I ask are whether the functionality need to be reused/shared and, if so, at what level? In your case, at least some of the business objects need to be shared by different modules. So, it may be prudent to put the business objects that are common to multiple modules into a single assembly that can be shared across modules. Then, the individual modules can be in separate assemblies (projects) that reference the common library (much like you do with CSLA).
It is possible that some of your 1200 tables (with CSLA, the number of entities would be different because it is behavior-based not data-based) are relevant only to specific modules and these should not be in the shared assembly. Only code that actually needs to be shared can go here. And there can be multiple layers.
Next, I ask if there is a logic separation. For instance, anything UI related goes into a different assembly then my business objects and likewise with data access and so on.
A lot of this can be determined by your overall architecture. For instance, I work with several product families and many of the individual products support multiple UI technologies (web, windows, mobile, ...). We have many objects that are shared across product families, this forms the lowest layer in our model, then more that are shared only within the product families, the next layer, followed by the types specific to a product, the middle layer, then our presentation components and, finally, the application (UI) layer itself. For example, we have:
We have a platform team responsible for the company-wide assemblies and an architecture team within each product family responsible for the assemblies shared across that family's products. Then, we have product teams that work on the individual products with some developers focused on business logic, some on UI, others on the back-end DB and so on.
The final consideration for modularity is extensibility. Is there a reason why you would need different Relationship Management functionality in one deployment then in another? If not, then why split them apart? This may actually make the code more tedious to work with. On the other hand, if you have two different Relationship Management modules that can be swapped to provide two different "versions" of the application, then they should absolutely be in separate assemblies. Following the example above, we would have:
and our UI applications would make use of these modules. For extensibility, the dependant code would use interfaces so that the implementation types could be swapped out. The interfaces would be defined in Acme.MySuite.MyApp.Library which is used by both modules.
Note, I don't use deployment, maintenance of upgrades as a basis for modularity. It makes no difference to me if I have to deploy one large or several smaller assemblies, I still have to deploy.
With a good source control, having many users working on the same code base is not much of an issue. Like I said, I have a large team working at all levels on our products without issue.
If you want another perspective, take a look at how many (actually, how few) dll's there are for the Microsoft Office products and consider how many developers over a vast geographic area they have working on those products.
Hope that helps.
Thats a long reply ;)
Anyway we are a business to business company and one of our main products is nearly everywhere the same except differend based on licences. Only big clients pay extra money to see custom work into the product. A differend module. We'll just have 15 differend modules with differend functionality of which 2 or 3 might be differend at a later time. Lets say Customermanagement.dll and CustomermanagementLight.dll for example.
We are running on a Team Foundation Server, but not with much experience yet. Im in the farm admin group and there isn't any project really being developed in it yet. Just all new hehe.
I was thinking about splitting up the modules based on licences with functionality blocks. It might yust be that one assembly an businessobject CustomerInfo be in a shared library. Enumerations, constants, etc as well then. Until now i was thinking about interface libraries in which the interface Info businessobjects would be exposed to other libraries.
Copyright (c) Marimer LLC