Re: in need of a pattern


H. S. Lahman wrote:

A classic problem of changing one's mind about persistence mechanisms.


You got that right!

I am less sanguine about a conversion that "wouldn't be much" trouble.
Applications that old typically do not have good application
partitioning and the persistence access code would littered throughout
the solution logic.

True.

Thanks for the UI analogy, it really helps. But,...

So what you need is a strategy for identifying things that can be used
consistently by both the problem solution and the RDB access. But since
the abstraction are quite different (Student/Graduating Year vs.
Table/Attribute), each regime interprets that identity differently.
Once the identity strategy is defined it becomes relatively trivial to
provide the initialization data for constructing things like SQL
strings. However,...


Confused about the "indentity strategy". Is this a mapping between
Student/Graduating Year in the problem solution and the mechanism for
looking up a Student and Graduating Year in the persistence access
solution (which for a RDB would probably be a Table and a column )?

Alas, I'll bet the existing application has nothing close to that level
of isolation in the application partitioning. So to get where you need

How'd you ever get that idea :)?

If you choose to go the subsystem/layer route then I strongly suggest a
piecemeal strategy. First design the interface. Then insert it into
the existing application around the existing data access code. That
allows you to do full regression testing to make sure that the interface
itself hasn't broken anything. (Most of the refactoring will be in this
step.) Once you can access the old data persistence with the new
interface, design and implement the new RDB access subsystem to service
the new interface you have designed. Since it has a pure data transfer
interface you can thoroughly test it outside the application context.
Then the only thing left if to excise the old access code and plug in
the new subsystem.


Thanks for the advice.

Bonus: if you design the persistence access subsystem generically around
the RDB invariants (Table, Tuple, etc.) and you provide external
configuration data for identity (e.g., to plug into SQL strings), you
will find that you can reuse that subsystem for different applications
that access an RDB. For the reuse context you just need to provide a
new interface and new configuration data for identity. All the
implementation details like constructing SQL strings and decoding
datasets should pretty much Just Work in the new context.


Once again, not sure about "configuration data for identity".

[BTW, my blog deals with several of these issues in various categories.]


heading over there right now.

Thank you for your thoughts and the time it took to transcribe them.

Brian

.

Relevant Pages

  • Re: in need of a pattern
    ... over to a relational database. ... To deal with RDB access one just needs to raise the level of abstraction. ... That's how GUI builder tools exist; they provide identity mapping and external configuration data that allows the GUI screens to be initialized properly using data from the problem solution. ... If the interface is designed around the problem solution's needs for data, then changing the persistence mechanisms will not affect the problem solution because the interface will stay the same. ...
    (comp.object)
  • Re: Object Orientation in VB.NET
    ... a cardinal rule of OO development is: solve the customer problem first and then worry about how to map that solution into persistence mechanisms. ... The reason is that OO solutions do not usually map 1:1 to RDB tables despite that fact that the relational data model underlies both views. ... Then that subsystem is responsible for providing the conversion rules between the two views. ... That allows one to change the persistence mechanisms without touching the problem solution logic in any way. ...
    (comp.object)
  • Re: best practice design of this simple example - your thoughts?
    ... objects and RDB table rows is the exception rather than the rule. ... The other important difference is that the UI and persistence are decoupled from the problem solution ... That decoupling is through a message-based subsystem interface. ...
    (comp.object)
  • Re: best practice design of this simple example - your thoughts?
    ... objects and RDB table rows is the exception rather than the rule. ... The other important difference is that the UI and persistence are ... decoupled from the problem solution ... That decoupling is through a message-based subsystem interface. ...
    (comp.object)
  • Re: No knowledge of the database?
    ... can answer Yes because neither system used an RDB; ... any dependence on it persistence being through an RDB. ... would have a subsystem where knowledge of RDBs would be ... interface subsystem one has classes like Window and Control. ...
    (comp.object)