Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)

From: topmind <topmind_at_technologist.com>
Date: 2 Jun 2006 17:14:14 -0700
Message-ID: <1149293654.884843.23780_at_i40g2000cwc.googlegroups.com>


> My interpretation of RCM's stance is that one should simply decouple
> database from the domain model in the similar fashion as one should
> decouple UI from the domain model. This then makes the domain logic pure
> and independent of persistence as well as UI representational technology.

As far as GUI separation, may I reference this discussion:

http://www.c2.com/cgi/wiki?SeparateDomainFromPresentation

My view is that heavy separation is not very practical for most apps. The up-front and short-term cost of separation is roughly about 30 percent. The scenarios that separation tries to "protect" one from are too rare to make up for this 30% Separation Tax.

If you know up front you have to serve multiple DB or GUI vendors/API's, *then* heavy separation makes economic sense.

A compromise is little "helper" functions or API's that wrap the most common DB/GUI idioms used by a *particular* app. Such "helpers" should be disposable such that your app is not married to them. They are merely optional shortcuts. For example, in web apps I might create a FormatCell(...) function/object/tag that creates the HTML needed for a report/form cell or prompt. If a particular cell needs something beyond what FormatCell can handle, I simply switch to HTML for that one. Multi-app generic-intended wrappers fall on their face very easily because they grow bloated trying to handle every new variation that pops up (and users/managers are very creative with the variations they invent). In short, local "lite" re-use works; generic grandiose re-use does not, at least not for custom biz apps.

-T- Received on Sat Jun 03 2006 - 02:14:14 CEST

Original text of this message