Relational database & OO
in [OOP]
|
From: aloha.kakuikanu on 3 Nov 2006 22:18 Robert Martin wrote: > On 2006-11-02 15:17:45 -0600, "aloha.kakuikanu" > <aloha.kakuikanu(a)yahoo.com> said: > > > 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. > > This is very good advice. I would add the DRY principle. "Don't > Repeat Yourself" (See "The Pragmatic Programmer" by Dave Thomas and > Andy Hunt). > > For example, if you find yourself building the same SQL query in more > than one place, or a similar query, then consolidate that code into a > single module, which will probably be a class. Yes, if a SQL query is repeated in 2 places, then the surrounding JDBC glue code is repeated as well. It should be refactored into a single function. This doesn't really change the fact that SQL remains inlined into java code, so that the code is still very readable. It is not uncommon for OOP folks to extend your idea, and insist that one should always refactor SQL code into a dedicated module. Even if you don't have to, just in case if some other part of the system may require the same query. I suggest that the cases where you need the same query are exceptions rather than norm. If you have duplicating query, perhaps, you should reexamine your functionality? Chances are it is a design flaw.
From: frebe73 on 4 Nov 2006 02:07 > Yes, if a SQL query is repeated in 2 places, then the surrounding JDBC > glue code is repeated as well. It should be refactored into a single > function. This doesn't really change the fact that SQL remains inlined > into java code, so that the code is still very readable. It also depends on the size and complexity of the SQL statement. If the SQL statement are simple like select id, description from company where city=? or update employee set status=? where id=? there are still no reasons to put it into a separate function, even if it is called from multiple points. The function call itself will have the same verbosity as the SQL statement. Fredrik Bertilsson http://frebe.php0h.com
From: frebe73 on 4 Nov 2006 02:30 > Oy. I know this is bad form, but I can't help it. From dictionary.com: > storeâ?? /stÉ?r, stoÊ?r/ [stawr, stohr] â??verb (used with object) > 8. to supply or stock with something, as for future use. > 9. to accumulate or put away, for future use (usually fol. by up or > away). > 10. to deposit in a storehouse, warehouse, or other place for keeping. > 11. Computers. to put or retain (data) in a memory unit. > > Last time I checked, RAM was considered to be a memory unit. And I'm > pretty sure I've read plenty of talk about 'storing' data in a stack, > list, or some other ADT. If the word 'store' is no longer allowed to > refer to anything other than disk writes, I never got the memo. In that case, calling object.setSomething(data) is also about "storing". Actually a program is all about storing, because you store data in different variables all the time. In other words, "store" is not a very useful word in this context. I didn't introduce the word "store" in this thread. I was talking about "persistence" and the common misconception that a RDBMS is mainly used for persistence, and that using SQL would reveal anything about how data is persisted. > Evidently > 'persistence' evokes very different concepts in my mind and in yours, > perhaps as a result of different development backgrounds? Everybody with a solid background using RDBMS knows that a RDBMS is about much more than persistence, and would still use a RDBMS even if persistence is not needed. Many people from OO-land implements a lot of data management features by them self in every application, instead of using the features already provided by the RDBMS, and uses the RDBMS only for persistence. If you want to, I can give you real-world examples with the various downsides with this approach. Fredrik Bertilsson http://frebe.php0h.com
From: sjdevnull@yahoo.com on 4 Nov 2006 05:00 aloha.kakuikanu wrote: > 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. All excellent advice. > Embed all the SQL in java code, because it is the most simple, > readable and easily maintainable way to program database application. This doesn't make sense to me. If you're going to take the time to force all your database calls through one language, you're better off just doing an full mandatory database layer from the start without embedded SQL calls. In limited cases, mandating only one language for DB access may be desirable (e.g to ease the burden of installing appropriate database connectors for multiple libraries). But in general, if you do mandate one language then you might as well mandate a full-featured DB layer--much of the benefit of allowing ad-hoc SQL calls is lost if you can't do it in the same language as the rest of the application. Whatever you choose, if you do use embedded SQL (which I think is usually a good idea in practice) you _must_ be rigorous about factoring out any nontrivial queries that are repeated more than once.
From: frebe73 on 4 Nov 2006 07:03
> > Embed all the SQL in java code, because it is the most simple, > > readable and easily maintainable way to program database application. > > This doesn't make sense to me. If you're going to take the time to > force all your database calls through one language, you're better off > just doing an full mandatory database layer from the start without > embedded SQL calls. This doesn't make sense to me. What different languages are you talkning about. Who is talking time to forcing anything. The original statement was to use SQL whenever it is appropiate, not forcing it into a special layer. > In limited cases, mandating only one language for > DB access may be desirable (e.g to ease the burden of installing > appropriate database connectors for multiple libraries). All languages should be allowed to embedd SQL. > But in general, if you do mandate one language then you might as well > mandate a full-featured DB layer Nobody mandated only one language. > Whatever you choose, if you do use embedded SQL (which I think is > usually a good idea in practice) you _must_ be rigorous about factoring > out any nontrivial queries that are repeated more than once. Of course. But this is the fact with all code fragements. As soon as you have a nontrivial fragement of code that are repeated more than once you should to factory out it into a function. That is the art or programming. Fredrik Bertilsson http://frebe.php0h.com |