Enterprise Application Design with CSLA

Enterprise Application Design with CSLA

Old forum URL: forums.lhotka.net/forums/t/6175.aspx


gwilliams posted on Thursday, January 15, 2009

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.

sergeyb replied on Friday, January 16, 2009

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

cid:_2_0648EA840648E85C001BBCB886257279
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.



sergeyb replied on Friday, January 16, 2009

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

cid:_2_0648EA840648E85C001BBCB886257279
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

cid:_2_0648EA840648E85C001BBCB886257279
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.

 



gwilliams replied on Friday, January 16, 2009

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.

 

RockfordLhotka replied on Friday, January 16, 2009

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.

gwilliams replied on Monday, February 09, 2009

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?

RockfordLhotka replied on Monday, February 09, 2009

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

 

gwilliams replied on Monday, February 09, 2009

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?

RockfordLhotka replied on Monday, February 09, 2009

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?



ajj3085 replied on Monday, February 09, 2009

Yes, you should start as three different BOs for the address.  If at the end of the day they share all or most of their same behavior, then you may want to refactor the code to see if any reuse is possible.  Later down the line, if the behaviors diverge, you can split them later.

You can also have some reuse of your data code.  This is probably safer.  I have an internal class AddressData, and IAddress internal interface.  My BOs explicitly implement the interface (so the UI layer can't see it) and the AddressData class will handle insert update, fetch and delete operations for any type that implements the IAddress interface. 

The BO then calls the appropiate method in AddressData, and then once it's done it's work, the BO itself knows how to create the relationship between the address and the parent BO.

HTH
Andy

Copyright (c) Marimer LLC