Anyone share their Business Objects across multiple projects?Anyone share their Business Objects across multiple projects?
Old forum URL: forums.lhotka.net/forums/t/5995.aspx
reagan123 posted on Monday, December 15, 2008
Just curious to see if anyone here shares their business objects across multiple projects. We are thinking about using CSLA in all of our software applications and see some objects/use cases that are the same in each application (i.e. Entering/Updating a Person).
Is the best bet to put those common classes in their own project and then reference that dll from each of our projects or is this asking for problems.
I guess the main thing i'm trying to figure out is best way to leverage the existing or common objects across mulitple projects.
Thanks for any insight or tips.
ajj3085 replied on Monday, December 15, 2008
If the use case is always the same, there's no problem with this. If later things diverge, you can copy what you have into your project specific assembly and modify the behavior in those classes.
james phe replied on Monday, December 15, 2008
I'm very interested in this topic.I want create some standard BO for special domain,so I can extend those BO in each project.But I'm not sure this is the right way.
rsbaker0 replied on Tuesday, December 16, 2008
Yes, I have done this.
One possible hurdle is that CSLA out of the box only supports a single data portal, so that if you are fetching or persisting objects into two or more places, it can get interesting.
You may need to come up with a scheme where something about the BO class itself determines where the data is stored.
I've also made a slight modification to CSLA to support dynamic data portals, with the type of the BO being used to determine which data portal to use. In my specific case, I was trying to share our application library with a new disconnectable application, so the application libary is accessed via a web service or remote portal, and the local application data is forced through the local data portal. It works great.
SonOfPirate replied on Wednesday, December 17, 2008
I work in an environment with multiple product families each containing multiple products and we try to reuse code as much as possible and appropriate.
To accomplish this, we have a tiered structure for our framework libraries:
- Acme - all code that is product & family independant that is shared across the company. This is where we build upon CSLA.
- Acme.Web - product & familiy independant code for Web apps (common controls, etc.)
- Acme.Windows - same for WinForms apps
- Acme.Wpf - you get the point
- Acme.ProductFamily - code that is shared between all products within a family. Builds upon Acme
- Acme.ProductFamily.Web - builds on Acme.Web with stuff shared by the product family.
- etc.
- Acme.ProductFamily.Product - application specific stuff. Builds upon Acme.ProductFamily
- Acme.ProductFamily.Product.Web - web application for the product (if applicable). Uses the Acme.ProductFamily.Product and Acme.ProductFamily.Web libraries.
This is, of course, just one way to build out your framework to support reuse. What's nice about this approach is that we implement from the highest level down. This means that we first develop for the application that requires the behavior then, as we identify needs to share, that code can move down into the framework as we feel is appropriate.
(Replace Acme with Microsoft, ProductFamily with Office and Product with Word if that helps.)
Copyright (c) Marimer LLC
