RE: Separation of Objects from Logic 2004-12-20 - By Philip Nelson
> access layer. In a domain model based architecture, objects in the business
> logic layer should encapsulate all the state and methods that define what it
> is to be each modelled entity. That way, all the business logic for each
> entity is defined in one easily understandable and easily testable place.
Easily testable may be a stretch, but that's a different story ;-)
> In contrast, as I read the second technique it involves a two-tier business
> logic layer - one of which contains lightweight state containers, and the
> second of which contains the methods that acts on those containers.
OK, what if you use the second approach, and treat the "lightweight state
container" (acronym lsc) as a Memento?
class FrontFacingLogic
public FrontFacingLogic(SpecficStateContainer lsc) {this._state = lsc;}
public string Name {
get {return _state.Name;}
set {_state.Name = value;}
}
internal SpecificStateContainer GetState {return state;}
}
There are other possibilities for accessing the state by the persistence logic,
including keeping a reference to it keyed by the instance in a hashtable.
I bring this up because many OR mapping tools are not actually that great at
allowing you to customize the persistent classes they generate and end up
looking more like the DTO of the original poster's option 2.
=====
Philip - http://blogs.xcskiwinn.org/panmanphil
"There's a difference between righteous anger and just being crabby" - Barbara
Need SQL Advice? http://sqladvice.com
Need RegEx Advice? http://regexadvice.com
Need XML Advice? http://xmladvice.com
|
|
