Relational database & OO
in [OOP]
|
From: aloha.kakuikanu on 2 Nov 2006 16:17 Doug Pardee wrote: > ajspowart(a)gmail.com wrote: > > when it comes to creating an OO application that uses a relational > > database to store most of its data, how do people go about designing > > and storing the data once it has been retrieved from the database? > > Do you keep it as records, or when you get the data, do you create > > collections of objects which represent the data which you have > > obtained from your database? > > Martin Fowler's book "Patterns of Enterprise Application Architecture" > covers this territory. It would be a good starting point. Or yeah. A tiny time management application certainly needs to be hammered with "Enterprise strength" approach. Keep it simple. Write a minimal amount of code that transfers the information from the database to the GUI. Don't create classes unless you really forced to. Ignore all the temptations to design for "future extensibilty" -- just admit you don't have crystall ball to know the future. Embed all the SQL in java code, because it is the most simple, readable and easily maintainable way to program database application.
From: AndyW on 2 Nov 2006 17:40 On Thu, 02 Nov 2006 17:21:51 GMT, "H. S. Lahman" <h.lahman(a)verizon.net> wrote: >Responding to Ajspowart... > >> My question relates to good design when it comes to creating an OO >> application that uses a relational database to store most of its data, >> how do people go about designing and storing the data once it has been >> retrieved from the database? Do you keep it as records, or when you get >> the data, do you create collections of objects which represent the data >> which you have obtained from your database? >> >> I am wanting to create an application that is for time management and I >> want most of the data to be on my webservers database, but in creating >> my OO 'client' I really want to create a good design. > >I assume the time management application does something complex rather >than simply acting as a pipeline between RDb and UI (i.e., CRUD/USER >processing). If not, you can stop reading. > >Solving a time management problem is a quite different subject matter >than persisting the relevant data. Solve the time management problem in >you application first. Then, when you know what object attributes need >to be persisted, define a suitable Data Model for the database. The RDB >Data Model and the solution's Class Model will typically be different >for non-CRUD/USER applications because they need to be optimized >differently. I agree with the solution, but I really think one is talking about a Persistant Storage Engine (PSE) rather than perhaps an OO database. A PSE can often be implemented using an object schema or RDB model. The difference between what I think should be a true OO database and a PSE is that to me the former has no separation of state between what is executing and what is stored. There shouldnt be any concept of storage or transience or separation of application and data - just "IS-ness of the whole" as I call it. I made the comment in another thread that OO does not have a concept of transience - its a programmers abstraction and probably the cause of many RDB vs OO DB debates.. Once a developer starts talking about persistance and those related terms they are talking about separation of data and code and to be honest, they may as well use an RDB. I've always felt that a good way to understand OO DB concepts is to do some CORBA development. One calls an interface on an object in ones client application, the fact that the behind the scenes execution is done in a different country on the other side of the world and may or may not invovle a cluster of database servers (object or relational) is completely transparent to the client developer. To the client - things just happen. Andy
From: frebe73 on 3 Nov 2006 00:53 > Once a developer starts talking about persistance and those related > terms they are talking about separation of data and code and to be > honest, they may as well use an RDB. If the developer uses a RDB, he will not have to care about the persistance aspect at all. Persistence is a feature at the bottom of the RDB stack. The user of a RDB doesn't know of the data he is working with is cached or actually read from disk. Even if persistence is not needed, one would probably need a RDB for all other features. > I've always felt that a good way to understand OO DB concepts is to do > some CORBA development. One calls an interface on an object in ones > client application, the fact that the behind the scenes execution is > done in a different country on the other side of the world and may or > may not invovle a cluster of database servers (object or relational) > is completely transparent to the client developer. To the client - > things just happen. The same could be said about SQL and ODBC/JDBC/ADO. The fact that behind the scenes execution is done using a all-in-memory lightweight database or a monster database like DB2 is completely transparent to the client developer. Fredrik Bertilsson
From: Matt McGill on 3 Nov 2006 07:54 frebe73(a)gmail.com wrote: > > Once a developer starts talking about persistance and those related > > terms they are talking about separation of data and code and to be > > honest, they may as well use an RDB. > > If the developer uses a RDB, he will not have to care about the > persistance aspect at all. Persistence is a feature at the bottom of > the RDB stack. The user of a RDB doesn't know of the data he is working > with is cached or actually read from disk. Even if persistence is not > needed, one would probably need a RDB for all other features. An RDBMS does a great job of handling all of that mess, and more (ACID transactions are the real kicker - thank goodness we don't have to re-implement /that/ wheel) for _data_, but the OO programmer who wants her _objects_ (data married to related behavior) to 'persist' across multiple user sessions/program executions/phases of the moon is working at a somewhat higher level. The problem then becomes one of instantiating relationships - if an object is persistent, it needs to be loaded from the storage mechanism at some point. Who does that? Who loads other persistent objects associated with the first? Where are the transaction boundaries? If these persistence-related concerns are sprinkled about your business logic, your code will be much harder to adapt to changing requirements. Quoting AndyW: >> The difference between what I think should be a true OO database and a >> PSE is that to me the former has no separation of state between what >> is executing and what is stored. There shouldnt be any concept of >> storage or transience or separation of application and data - just >> "IS-ness of the whole" as I call it. >> >> I made the comment in another thread that OO does not have a concept >> of transience - its a programmers abstraction and probably the cause >> of many RDB vs OO DB debates.. I agree - unfortunately, for those of us still doing ORM, the frameworks available still require you to do a lot of grunt work to maintain your objects. Hibernate, for example, is designed for fairly short 'sessions' of work which will be persisted. When a Session has closed, the objects loaded in that session are considered 'detached,' and changes to their internal state will not be persisted unless they are merge()ed with another Session. Worse, accessing a lazily-loaded collection on a detached object throws an exception, because the Session is closed and the collection proxy has no way of obtaining its objects. I've been lately relying on a combination of AOP and transitive persistence to try and seperate these sorts of persistence concerns out from the rest of my code entirely. Spring has some useful AOP helper classes which allow for declarative transaction demarcation, which is one piece of the puzzle. I've written some of my own AOP wrappers for re-attaching detached objects to new sessions automagically. Making use of Hibernate's transitive persistence mechanism to transparently cascade re-attachments when necessary completes the picture. Using these techniques, the high-level application and business logic for our current app has stayed *very* clean and simple - significant program changes have been comparatively easy because there is no persistence-related code which needs to change when the business logic needs to change. What's been /really/ interesting has been trying to allow for relationships between objects which are persisted to entirely different data stores =) I haven't pinned down a good way to do this with Hibernate just yet (assuming one can be found).
From: frebe73 on 3 Nov 2006 10:12
> but the OO programmer who wants > her _objects_ (data married to related behavior) to 'persist' across > multiple user sessions/program executions/phases of the moon is working > at a somewhat higher level. If the OO programmer only needs persistence, and RDBMS is a huge overkill. A much simpler tool would do. > The problem then becomes one of > instantiating relationships - if an object is persistent, it needs to > be loaded from the storage mechanism at some point. Who does that? Who > loads other persistent objects associated with the first? Where are the > transaction boundaries? A RDBMS is not a storage mechanism. A storage mechnism is much simpler. Transactions and persistence are two orthogonal features. > If these persistence-related concerns are > sprinkled about your business logic, your code will be much harder to > adapt to changing requirements. If you use SQL in your application, your application will contain no persistence related logic at all. Fredrik Bertilsson |