I am hoping someone can shed some light on a current topic of discussion with all of our development managers.
All of our applications utilize 6 common objects; however we do not have Common objects built.
For example all our applications have a Person object ( name, address(s), phone(s), and a collection of attributes specific to the application ). These “objects” may be a data table, dataset, or class file. Also, each application has it own database.
I have used CSLA in another application and would like to use the framework to build an “Enterprise” wide set of Objects that all applications can use.
My question is what would be the best way to architect this so that I am not creating a copy of a base library project and changing out the DAL for each application that is built.
As long as you can decipher DAL specifics from app’s
configuration file, you can create a common library with just common classes
and a reference to it in all of your solutions. Custom properties for
each app though would be a challenge though. You could put all properties
into the base class and teach it how to behave differently based on configuration
file.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: gwilliams
[mailto:cslanet@lhotka.net]
Sent: Thursday, January 15, 2009 10:40 PM
To: Sergey Barskiy
Subject: [CSLA .NET] Enterprise Application Design with CSLA
I
am hoping someone can shed some light on a current topic of discussion with all
of our development managers.
All
of our applications utilize 6 common objects; however we do not have Common
objects built.
For
example all our applications have a Person object ( name, address(s), phone(s),
and a collection of attributes specific to the application ). These
???objects??? may be a data table, dataset, or class file. Also, each
application has it own database.
I
have used CSLA in another application and would like to use the framework to
build an ???Enterprise??? wide set of Objects that all applications can use.
My
question is what would be the best way to architect this so that I am not
creating a copy of a base library project and changing out the DAL for each
application that is built.
Then again, this would increase coupling between possibly
unrelated applications, so I would suggest approach common library with
caution.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: Sergey Barskiy
[mailto:cslanet@lhotka.net]
Sent: Friday, January 16, 2009 8:12 AM
To: Sergey Barskiy
Subject: RE: [CSLA .NET] Enterprise Application Design with CSLA
As long as you can decipher DAL specifics from app’s
configuration file, you can create a common library with just common classes
and a reference to it in all of your solutions. Custom properties for
each app though would be a challenge though. You could put all properties
into the base class and teach it how to behave differently based on
configuration file.
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: gwilliams
[mailto:cslanet@lhotka.net]
Sent: Thursday, January 15, 2009 10:40 PM
To: Sergey Barskiy
Subject: [CSLA .NET] Enterprise Application Design with CSLA
I
am hoping someone can shed some light on a current topic of discussion with all
of our development managers.
All
of our applications utilize 6 common objects; however we do not have Common
objects built.
For
example all our applications have a Person object ( name, address(s), phone(s),
and a collection of attributes specific to the application ). These
???objects??? may be a data table, dataset, or class file. Also, each
application has it own database.
I
have used CSLA in another application and would like to use the framework to
build an ???Enterprise??? wide set of Objects that all applications can use.
My
question is what would be the best way to architect this so that I am not
creating a copy of a base library project and changing out the DAL for each
application that is built.
Thanks for the prompt reply. The DAL component is really what is causing me all the heartburn. It seems to me it is the only real concrete part of the CSLA object. I could add additional properties to the object that would hold DAL configurations and treat the application specific attributes as separate objects and not as "true" children of the parent object.
My end goal is to have all our dev teams utilize a common programming methodology. we have to many people doing to many different things and creating really the same objects. This has led us to have 8 database that hold identical data with no real business reason to keep them all separate. With all these applications being utilized internally I think this is a waste of resources.
I recommend against this approach.
This sort of thing was tried in the late 90s and early 00s, and I've never seen a company make it work.
The idea of coupling all your applications to a common set of objects causes so much trouble it can't be beneficial. Can you really create a Customer object that has all the rules and behaviors and meets the performance requirements for every scenario where you use, edit or interact with customer data? And even if you can create such a thing, how massive will that one class become?
Are the rules for using customer data the same in the 'edit a customer' and 'enter an order' scenarios? And the 'set up AR for a customer' scenario? Almost certainly not. So your "Customer object to rule them all" will be chock full of conditional statements:
If <in scenario 1>
DoScenario1Stuff
Else If <in scenario 2>
Do Scenario2Stuff
...
Debugging this will be virtually impossible. Identifying the side-effects of each scenario on any other scenario and/or the data will be virtually impossible.
The closest analogy to this model that I'm aware of, are the massive COBOL modules that were common 20 years ago.
Coupling is probably the single biggest roadblock to maintainability. Reuse of code leads to coupling. While reuse seems good, it is only good if you can achieve it with minimal coupling. Otherwise the cost of coupling totally outweighs the benefit of reuse and the result is a net loss.
That makes sense. One more questions along the same line..
I have multiple objects that have Address information as a child object. The only difference in the data being collected is the relationship to the other object.
example. Person to Address, trip to address, facility to address. Ect. Should each of these address objects be specific to each object.. meaning I would have 3 address objects tied directly to the object they support.
The only different in the address object would again be the DAL to create the relationship in the proper table.
My thought would be yes… even though the difference is minor it is still a difference. Correct?
That is true, if they include the DAL code they should be
different classes.
If you are using an architecture with a separate DAL you could
consider having one class (assuming _all_ other behaviors are the same).
This can work well if your DAL is abstract enough that the Address class just
passes some “type token” through to the DAL so the DAL knows which
type of data to retrieve.
Rocky
I was going to be using a separate DAL. My initial thought was to set a "Type" property within the Address BO and then in the DAL check for what type and execute the appropriate proc. Was not sure if this would start confusing the matter; one object doing more then one thing.
Thanks for your thoughts on all of this. I now have all 3 of your books and pushing hard to implement the framework as standard coding practices for my group. Can you recommend a trainer in the Denver area for the 3.6 CSLA framework?
For training I recommend Dunn Training. They have 3 day and 5
day classes on CSLA .NET and so a great job.
Rocky
From: gwilliams
[mailto:cslanet@lhotka.net]
Sent: Monday, February 09, 2009 10:49 AM
To: rocky@lhotka.net
Subject: Re: [CSLA .NET] RE: Enterprise Application Design with CSLA
I was going to be using a separate DAL. My initial thought was to set a
"Type" property within the Address BO and then in the DAL check for
what type and execute the appropriate proc. Was not sure if this would start
confusing the matter; one object doing more then one thing.
Thanks for your thoughts on all of this. I now have all 3 of your books and
pushing hard to implement the framework as standard coding practices for my
group. Can you recommend a trainer in the Denver area for the 3.6 CSLA
framework?
Copyright (c) Marimer LLC