OOP and Persistence
In the spirit of ask don't tell and never let an object get into an
invalid state oop design, I'm wondering how persistence would be handled
in a dynamic environment.
For a contrived example, imagine you need to write a POS application for
an airline. You can only sell seats that are available. Seats are grouped
such that plane -> sections -> rows -> seats. If a section is unavailable
then all rows and therefore seats in that section are also unavailable.
And obviously if a row in unavailable then all seats in the row are also
not available.
Now the environment is highly dynamic in that maintenance personnel may be
making sections, rows, or seats available/unavailable frequently. Further,
imagine it's somewhat expensive to build the airplane object graph.
However without constructing the entire graph for each sale attempt I
don't see how you can keep business rules out of the persistence layer,
which in my mind is an absolute must.
Is oop just not a viable choice for this kind of problem?
No comments:
Post a Comment