Discussions

News: Article: Spring in Action

  1. Article: Spring in Action (42 messages)

    This article is an excerpt from Better, Faster, Lighter Java which discusses adding persistence to the PetStore example, and looking at the area of presentation logic in the Spring framework. Bruce Tate has also been busy with his analogies on java.net.

    Spring in Action, Part 2

    Spring in Action, Part 1

    Bruce's thoughts

    Good middleware

    WHERE'S THE CHICKEN?

    Bruce does love chicken, mountain biking, and cayaking :)

    Threaded Messages (42)

  2. no thanks[ Go to top ]

    The Spring JDBC layer uses a feature called callback templates to pass control from your application to the framework. With this strategy, Spring removes the need to manage connections, result sets, and RDBMS-specific errors.
    We all know how difficult it is to manage a jdbc connection. Let's see...setAutoCommit(), commit(), rollback(), close().

    And the ResultSet! I don't know what I would do with a ResultSet. Well, I guess I could loop through it and create objects... No, sounds too risky. I better jump on the O/R Mapping bandwagon before I hurt myself.
  3. no thanks[ Go to top ]

    We all know how difficult it is to manage a jdbc connection. Let's see...setAutoCommit(), commit(), rollback(), close().And the ResultSet! I don't know what I would do with a ResultSet. Well, I guess I could loop through it and create objects... No, sounds too risky. I better jump on the O/R Mapping bandwagon before I hurt myself.
    It's about avoiding all that repeated boilerplate code that just does resource handling, concentrating on the actual data access operation - even if you *could* do it manually. It's also about seamless transaction participation (i.e. the ability to participate in any kind of larger transaction), instead of hardcoding specific transaction demarcation in your data access operations.

    Have a look at my recent posting in another TSS thread: It shows some concrete examples, i.e. simple and to-the-point data access operations implemented with Spring's support classes - which still have proper resource management and transaction participation, despite their conciseness.

    http://theserverside.com/news/thread.tss?thread_id=27166#129199

    Juergen
  4. no thanks[ Go to top ]

    We all know how difficult it is to manage a jdbc connection. Let's see...setAutoCommit(), commit(), rollback(), close().And the ResultSet! I don't know what I would do with a ResultSet. Well, I guess I could loop through it and create objects... No, sounds too risky. I better jump on the O/R Mapping bandwagon before I hurt myself.
    It's about avoiding all that repeated boilerplate code that just does resource handling, concentrating on the actual data access operation - even if you *could* do it manually. It's also about seamless transaction participation (i.e. the ability to participate in any kind of larger transaction), instead of hardcoding specific transaction demarcation in your data access operations.Have a look at my recent posting in another TSS thread: It shows some concrete examples, i.e. simple and to-the-point data access operations implemented with Spring's support classes - which still have proper resource management and transaction participation, despite their conciseness.http://theserverside.com/news/thread.tss?thread_id=27166#129199Juergen
    Yes, I agree with every reason that you state. However, a well-defined DAO superclass does all of the above AND I did not have to spend any time learning specific syntax like this...
    Example 8-4. Product.xml

    [1] <sql-map name="Product">
     
    [2] <cache-model name="oneDayProduct" reference-type="WEAK"
            <flush-interval hours="24"/>
         </cache-model>

    [3] <result-map name="result" class="jpetstore.domain.Product">
           <property name="productId" column="PRODUCTID" columnIndex="1"/>
           <property name="name" column="NAME" columnIndex="2"/>
           <property name="description" column="DESCN" columnIndex="3"/>
           <property name="categoryId" column="CATEGORY" columnIndex="4"/>
         </result-map>

    [4] <mapped-statement name="getProduct" result-map="result">
           select PRODUCTID, NAME, DESCN, CATEGORY from PRODUCT where PRODUCTID = #value#
         </mapped-statement>

    [5] <mapped-statement name="getProductListByCategory" result-map="result">
           select PRODUCTID, NAME, DESCN, CATEGORY from PRODUCT where CATEGORY = #value#
         </mapped-statement>

    [6] <dynamic-mapped-statement name="searchProductList" result-map="result">
           select PRODUCTID, NAME, DESCN, CATEGORY from PRODUCT
           <dynamic prepend="WHERE">
              <iterate property="keywordList" open="(" close=")" conjunction="OR">
                lower(name) like #keywordList[]# OR lower(category)
    like #keywordList[]# OR lower(descn) like #keywordList[]#
              </iterate>
           </dynamic>
         </dynamic-mapped-statement>

        </sql-map>
  5. Since we're pasting code...I think you just pasted a bunch of random code out of context to make it look complex. If we isolate a single example, and compare it to the JDBC alternative, I think most will agree which is simpler:

    ---iBATIS-----------------------------------------------------

    <select id="getEmployee" parameterClass="int" resultClass="eg.domain.Employee">
      SELECT EMP_ID as id,
             NUMBER as empNumber,
             FIRST_NAME as firstName,
             LAST_NAME as lastName,
             TITLE as title
      FROM EMPLOYEE
      WHERE EMPLOYEE_NUMBER = #id#
    </select>

    Integer pk = new Integer(5);
    Employee emp = (Employee) sqlMap.queryForObject("getEmployee", pk);

    ---JDBC--------------------------------------------------------

    public Employee getEmployee (int id) throws SQLException {
        Employee employee = null;
        String sql = "SELECT * FROM EMPLOYEE " +
            "WHERE EMPLOYEE_NUMBER = ?";
        Connection conn = null;
        PreparedStatement ps = null;
        ResultSet rs = null;
        try {
          conn = dataSource.getConnection ();
          ps = conn.prepareStatement(sql);
          ps.setInt(1, id);
          rs = ps.executeQuery();
          employee = null;
          while (rs.next()) {
            employee = new Employee();
            employee.setId (rs.getInt("EMP_ID"));
            employee.setEmpNumber (rs.getInt("NUMBER"));
            employee.setFirstName (rs.getString("FIRST_NAME"));
            employee.setLastName (rs.getString("LAST_NAME"));
            employee.setTitle (rs.getString("TITLE"));
          }
        } finally {
          try {
            if (rs != null) rs.close();
          } finally {
            try {
              if (ps != null) ps.close();
            } finally {
              if (conn != null) conn.close();
            }
          }
        }
        return employee;
    }

    Employee emp = getEmployee (5);

    ---------------------------------------------------

    iBATIS isn't meant to solve every problem. But for those that it was meant to solve, it's much easier than JDBC.

    Cheers,
    Clinton
  6. Since we're pasting code...I think you just pasted a bunch of random code out of context to make it look complex.
    The code that I pasted came from the article that I was commenting on. That's the same article that I am commenting on now. The pasted code is not random.

    In the JDBC example that you posted you have a connection, result set, prepared statement and then a finally clause that closes everything. I have all of these things in my DAO superclass and need not repeat them in my DAO subclasses. So, my subclasses end up looking a lot like the iBATIS configuration that you supplied, only SQL.

    But the best part is I also have my own homegrown Code Generator that will write all of my DAO subclasses for me. I just point it to the database and it will write it all. The CodeGenerator also writes Domain, Facade, Struts Forms, whatever you like.

    Please use iBATIS if you like. I just don't think O/R is good because it throws more config files into my Java project.

    Cheers to you as well!
  7. I'm interrested![ Go to top ]

    Mr. Condition,

    Do you care to share this library of useful classes?

    Kind regards, Andreas Eriksson
  8. Please use iBATIS if you like. I just don't think O/R is good because it throws more config files into my Java project.
    It's a personal choice that the application developer can make for each project, depending on the particular requirements. Following Spring's supported data access strategies, there are the following basic options:

    1. Keep everything in DAO code, SQL queries as well as object/table mappings. Use JDBC support classes like Spring's JdbcTemplate here, which lead to very concise DAO implementations, without the need for custom base classes.

    2. Externalize SQL queries and object/table mappings into XML files, referencing them in your DAO code. Use iBATIS SQL Maps with Spring's SqlMap(Client)Template here, providing one-line operations.

    3. Externalize object/table mappings into XML files, but use an object query language/API. If you don't additionally need automatic change detection (because you explictly call store), OJB's PersistenceBroker API is a nice option. Use Spring's PersistenceBrokerTemplate for concise DAO operations.

    4. Externalize object/table mappings into XML files, use an object query language/API, and rely on automatic change detection instead of explicit store calls. This is the domain of Hibernate and JDO; use Spring's HibernateTemplate respectively JdoTemplate for implicit resource management.

    Neither is the first option always appropriate, nor is the latter. In particular, the latter persistence tools are significantly more complex: If you don't need automatic change detection, why fight with its implications and side effects? It all depends on your requirements.

    As a side note, Spring's DAO support classes can either be used within Spring's framework configuration model or in a library style. All you need to work with JdbcTemplate as library is a javax.sql.DataSource reference: new JdbcTemplate(dataSource), and off you go.

    Finally, externalizing mappings into XML files is not the only option: You can also generate those XML files from metadata attributes via XDoclet. Future tools will also support reading Java 5.0 metadata directly (as suggested by the EJB 3 draft).

    However, there *is* value in true externalization, IMO: If you use an O/R mapper, you lose some of the benefits when you include table and field names in source code again. It may be OK to have such metadata in DAOs, but I believe that persistent objects themselves should be free from mapping metadata.

    Juergen
  9. Mr. Condition is right in many ways, I have used and dropped many home made frameworks and O/R, I have used IBatis and DbUtils style data access in the past too, I have my legacy configuration frameworks, pools and spring style wrappers too.
    But I recomend to make this code public, you will find how it is crappy, OSS will help to make it better for yourself. CGLIB and Voruta was born this way too. There is nothing wrong with experiments, if you do not experiment it in production, OSS is a very good place to innovate. I advokate declarative programming and I plan to make some experiments public too. If you do not like spring for some reason or see something wrong in O/R then I think you is right, impement framework yourself.
  10. I have all of these things in my DAO superclass and need not repeat them in my DAO subclasses. So, my subclasses end up looking a lot like the iBATIS configuration that you supplied, only SQL.But the best part is I also have my own homegrown Code Generator that will write all of my DAO subclasses for me. I just point it to the database and it will write it all. The CodeGenerator also writes Domain, Facade, Struts Forms, whatever you like.
    So use it and shut the hell up. Just because you wrote a generator (you're lucky if you built it with Velocity, because I think that 'not invented here' is so strong on your side that you even didn't bother to write a middlegen or xdoclet or AndroMDA or SGen plugin) it doesn't mean DAO layers or ORM is useless. Actually I am sure that I twice as productive as you are by generating for iBATIS or Hibernate.

    But if I am right, and I know I am, you didn't use none of these but created a stupid generator that doesn't even support roundtrip dev and even if it does and at the start of a project we might consider at the same level of productivity as the project grows and requirements change drastically your development performance will decrease drastically because plain jdbc is not productivity anymore. Id doesn't even mean performance. If it does to you than you might want to win those 100 bucs Gavin is giving to the guy that *really* outperforms hibernate.

    So please don't come to me with 'this and that sucks' because it's starting to annoy me how more and more whiners appear here to spit their stupidity so that you can't read some usefull information because some smart ass like you thinks he invented God and than asked him to create the world.

    Please.
  11. There is also the maintenance aspect of such "home brew" frameworks: one day another person other than the original developer will have to support such code, and even if it happens to be well documented and all (few are), it will be a new API to be learned, incurring in time lost.
    If instead we try to leverage on common frameworks, there are higher chances of other people already know and be able to use them without having to spend time learning it. This means lower costs shorter schedules on the long run.
    There are also all the benefits of Open Source, so this concept of "home brew" being better can be relegated to very specific and unusual situations, where general solutions can't be applied properly.

    Regards,
    Henrique Steckelberg
  12. There is also the maintenance aspect of such "home brew" frameworks: one day another person other than the original developer will have to support such code, and even if it happens to be well documented and all (few are), it will be a new API to be learned, incurring in time lost. If instead we try to leverage on common frameworks, there are higher chances of other people already know and be able to use them without having to spend time learning it. This means lower costs shorter schedules on the long run. There are also all the benefits of Open Source, so this concept of "home brew" being better can be relegated to very specific and unusual situations, where general solutions can't be applied properly.Regards,Henrique Steckelberg
    Absolutely. At my current job we had a homegrown framework that was comparable to Struts tags as well as a homebrew of jdbc.

    Now, that stuff did the trick, but it incurs an alarming learning curve whenever someone new has to work on it and the original developer has moved on.

    My first task when I started was to migrate us to Struts. Because it is best? No, but it is standard. You can pull people off the street who are at least roughly familar with Struts and just need to understand our value-added code. We've also moved to Hibernate and it is paying off.

    I've been a following Spring since reading about it in Rod's first book and will now complete the trifecta by incorporating this. I look forward to learning Spring and learning *from* it.

    I'd rather standardize on reasonably popular technology and use it as a foundation for my work. Then, when the new people join, I can hand them a Struts, Spring, and Hibernate book and guess what? Instant documentation, a more shallow learning curve, and better products.

    And I still have room to innovate where I see fit.
  13. Open source[ Go to top ]

    And I still have room to innovate where I see fit.
    And open source is open. So if your innovation is really good, you can contribute it to one of those projects.
  14. I think it is better to keep trivial code at home or to fork some utils or some template for design pattern, it helps to reduce dependancies.
    If application depends on infrastructure framework it depends on framework life cycle too, I must be sure framework will live longer than my application. Maintenance is not a trivial aspect in both cases.
  15. Henrique: ”It will be a new API to be learned, incurring in time lost.”

    If the "new API" is only the 40 lines of code in Race Condition's Superclass maybe you can stand it. :)

    You need a little more though; a mapping of the table/column names to ensure that changing the fieldname doesn't break the code. (15 min work). And why not add a generic "sqlbuilder-object" too, to give you the possibility at one central point tweak the sql-statements (for instance to add security), all in all no more than about 200 lines of generic code.

    Then you have the full power of SQL at your disposal, you do not need to learn a new home-made query language and the results-sets can be a simple objectgraph, i. e. an arraylist of string collections.

    As it has been done it for 20-30 years and still works well. (no select * from")

    Regards
    Rolf Tollerud
  16. no need to learn anything[ Go to top ]

    Henrique: ”It will be a new API to be learned, incurring in time lost.”If the "new API" is only the 40 lines of code in Race Condition's Superclass maybe you can stand it. :)You need a little more though; a mapping of the table/column names to ensure that changing the fieldname doesn't break the code. (15 min work). And why not add a generic "sqlbuilder-object" too, to give you the possibility at one central point tweak the sql-statements (for instance to add security), all in all no more than about 200 lines of generic code.Then you have the full power of SQL at your disposal, you do not need to learn a new home-made query language and the results-sets can be a simple objectgraph, i. e. an arraylist of string collections.As it has been done it for 20-30 years and still works well. (no select * from")RegardsRolf Tollerud
    Here we go. We've got Race Condition as a smart ass for once. Than we've got Rolf jumping in and describing how 'things are done' in the last 20, 30 years. I only have to get Rolf out of his mind too and I can meet them both at the same time, first to teach Rolf that I, as the average java developer, will drink more beer than he would ever think it exists and second, to help Race Bill (according to Cameron's blog entry that Bruce pointed out) rewrite his generator as a SGen plugin because that's where the future of java code generation stands. Good day gentlemen.
  17. ...some smart ass like you thinks he invented God and than asked him to create the world. Please.
    Such harsh words, Dorel!
    You know I just spoke to God and she thinks you shouldn't be so angry with your posts to this site. By the way, God is studying for her Sun Java Architect Certification as we speak.
  18. Such harsh words, Dorel! You know I just spoke to God and she thinks you shouldn't be so angry with your posts to this site. By the way, God is studying for her Sun Java Architect Certification as we speak.
    Uuuuu, how impressive. Do you have to study to pass that ?
  19. You know I just spoke to God and she thinks you shouldn't be so angry with your posts to this site. By the way, God is studying for her Sun Java Architect Certification as we speak.
    Ahh, so it is Marc. How is Natalie ?
  20. I have all of these things in my DAO superclass and need not repeat them in my DAO subclasses. So, my subclasses end up looking a lot like the iBATIS configuration that you supplied, only SQL.But the best part is I also have my own homegrown Code Generator that will write all of my DAO subclasses for me. I just point it to the database and it will write it all. The CodeGenerator also writes Domain, Facade, Struts Forms, whatever you like.
    So use it and shut the hell up. Just because you wrote a generator (you're lucky if you built it with Velocity, because I think that 'not invented here' is so strong on your side that you even didn't bother to write a middlegen or xdoclet or AndroMDA or SGen plugin) it doesn't mean DAO layers or ORM is useless. Actually I am sure that I twice as productive as you are by generating for iBATIS or Hibernate. But if I am right, and I know I am, you didn't use none of these but created a stupid generator that doesn't even support roundtrip dev and even if it does and at the start of a project we might consider at the same level of productivity as the project grows and requirements change drastically your development performance will decrease drastically because plain jdbc is not productivity anymore. Id doesn't even mean performance. If it does to you than you might want to win those 100 bucs Gavin is giving to the guy that *really* outperforms hibernate.So please don't come to me with 'this and that sucks' because it's starting to annoy me how more and more whiners appear here to spit their stupidity so that you can't read some usefull information because some smart ass like you thinks he invented God and than asked him to create the world. Please.
    Dork-el,

    On second thought, I've decided to kick your ass. Where can I find you?
  21. Dork-el, On second thought, I've decided to kick your ass. Where can I find you?
    Okay, now that is funny! :-) A decision reached and still gentleman enough to ask directions.

    Race, I don't agree with your software assessments in this thread, but I do enjoy a good laugh.
  22. Explain how you generate code and how to remove duplicated code with DAO superclass, it is more meaningfull than to kick ass. I see nothing wrong in superclasses, but it is not clear from your post.
  23. example[ Go to top ]

    Explain how you generate code and how to remove duplicated code with DAO superclass, it is more meaningfull than to kick ass. I see nothing wrong in superclasses, but it is not clear from your post.
    Juozas,

    The superclass has two update methods, one takes an object the other takes an object and a connection. This way it can participate in a larger transaction. Notice how the superclass calls on the subclass to prepareUpdateStatement(o, conn). All of the jdbc/connection code is in superclass and needs not be repeated ever again. The subclass is responsible for building the prepared statement.


    public abstract class DaoSuperclassExample {

      protected abstract PreparedStatement prepareUpdateStatement(Object o, Connection conn) throws SQLException;


    public DomainObject update(Object o) throws SQLException {

    Connection conn = null;

    try {
    conn = getConnection();
    conn.setAutoCommit(false);
    update(o, conn);
    conn.commit();
    }
    catch (SQLException sqle) {
    if (conn != null) {
    conn.rollback();
    }
    throw sqle;
    }
    finally {
    close(null, null, conn);
    }

    return o;
    }

    public DomainObject update(Object o, Connection conn) throws SQLException {

    PreparedStatement ps = null;

    try {
    ps = prepareUpdateStatement(o, conn);
    ps.executeUpdate();
    }
    finally {
    close(null, ps, null);
    }

    return o;
    }

    }


    Have a good weekend!
  24. race condition...who are you?[ Go to top ]

    http://www.jroller.com/page/cpurdy/20040602
  25. that's right[ Go to top ]

    right
  26. example[ Go to top ]

    This project can be interesting for you, http://jakarta.apache.org/commons/dbutils. I have used this way before and I contributed some ideas too, but I think it is better to fork this kind of code.
  27. example[ Go to top ]

    Forgive me if I'm missing your point, but I see the points of an O/R framework as (in no particular order):

    a) Removing any embedded SQL statements (or having to write routines that allow you to extract them).
    b) Enabling the developer to easily map complex objects (with many dependencies) to a database.
    c) Enabling the developer to map to any database (SQL is hardly standard among providers these days!).
    d) Improving the ability to test code lightly.
    e) Removing any hard coded connection configuration.

    There are probably others, but these are what I have found important. I agree that DAO objects are handy, and I've used Hibernate wrapped in DAO objects on a couple of projects now and it's far more easy than writing SQL/JDBC.

    As for having to learn an XML schema... please if you have learned how to use SQL or JDBC, Spring's & Hibernate's XML schema should be a walk in the park.

    Good luck with maintaining your application in the future!
  28. example[ Go to top ]

    You are mising point, O/R is not about to remove SQL or "simple to use" It is a tool used to map OO and ER models. SQL and RDBMS is not your enemy, if you will understand and learn it then you will not need this transformation, things become easy after you learn it.
    Good luck with migrating your application to new popular workaround or back to SQL in the future :)
  29. example[ Go to top ]

    You are mising point, O/R is not about to remove SQL or "simple to use" It is a tool used to map OO and ER models. SQL and RDBMS is not your enemy, if you will understand and learn it then you will not need this transformation, things become easy after you learn it.Good luck with migrating your application to new popular workaround or back to SQL in the future :)
    I think many of us understand SQL and database and *still* see a need for OR mapping. What makes for a good relatonal database does not necessarily make for a good object model.

    If your model fits well, fine, but for many of us, having our model driven by a database design simply doesn't work well.

    Why is it when people don't like a particular approach, they inevitably state that the people who do lack some knowledge or insight only *they* seem to possess?
  30. example[ Go to top ]

    I do not have good ansver, O/R mapping has use cases, but it has problems too. I think O/R mapping is good if it can map any object (data structure is an object too). I prefer SQL and I think it was one of the best ideas in IT history and I see no meaning to reinvent it. SQL does not conflict with O/R mapping. I think it must be possible to implement good O/R mapping tool for people like me, I am trieng to do it myself too.
  31. example[ Go to top ]

    I do not have good ansver, O/R mapping has use cases, but it has problems too. I think O/R mapping is good if it can map any object (data structure is an object too). I prefer SQL and I think it was one of the best ideas in IT history and I see no meaning to reinvent it. SQL does not conflict with O/R mapping. I think it must be possible to implement good O/R mapping tool for people like me, I am trieng to do it myself too.
    I think that we are closer than farther. All I've ever asked of any OR tool is keep the simple things simple and allow me to go directly to SQL when I feel the need. I've personally ever seen OR mappers as a reinvention of SQL, but instead a logical extension. We inevitably move away from "close to the metal" to some higher abstraction. These abstractions, the good ones anyway, ultimately make it easier to do certain tasks which frees us up to create better abtractions, which make it easier to do certain tasks, which frees us up to create... A good OR mapper, to me is a tool like a vendor provided connection pool. It keeps me from being overly concerned with the mundane.

    The results - applications that are faster to write, more stable, more robust, more scalable, more maintainable, at least in my world.
  32. example[ Go to top ]

    The results - applications that are faster to write, more stable, more robust, more scalable, more maintainable, at least in my world.
    Yes, result is important, current popululism is not. If you know how to get better results with then it is ok.

    "Java developers to use existing relational database technology from Java without needing to know SQL or be an expert in relational database design"

    You can find this crap on JDO leader home page. It is lame, is not it ?
  33. example[ Go to top ]

    The results - applications that are faster to write, more stable, more robust, more scalable, more maintainable, at least in my world.
    Yes, result is important, current popululism is not. If you know how to get better results with then it is ok."Java developers to use existing relational database technology from Java without needing to know SQL or be an expert in relational database design"You can find this crap on JDO leader home page. It is lame, is not it ?
    Not necessarily. Let's say you have a persistence layer, with an API called getAllAccounts(int id) that returns a list of Accounts objects. Let's then say that you have a junior mid-level person who has a display a list of all accounts for a customer when he clicks on a customer link in the application.

    Where exactly did that person have to know SQL?

    Should you, at some point, learn SQL? Sure. But the programming world isn't where it was when I started 10 yrs ago. Less experienced people are doing more because of things like Hibernate and JDO. Perhaps that junior-midlevel person isn't writing that persistence API(yet) and the person who is should certainly have SQL in his war chest, the point of the API is the reduce(or eliminate) the need for using the lower level API.

    getAllAccounts(int id) does just that.
  34. example[ Go to top ]

    Not necessarily. Let's say you have a persistence layer, with an API called getAllAccounts(int id) that returns a list of Accounts objects. Let's then say that you have a junior mid-level person who has a display a list of all accounts for a customer when he clicks on a customer link in the application.Where exactly did that person have to know SQL?
    API user doe's not need to know JDOQL in this case too, it is nothing about O/R mapping too.

    BTW SQL is not any kind of programming, but JDBC and JDO are.
  35. example[ Go to top ]

    BTW Do you want to post this method implementation (code and metadata) using JDO ?

    this is my way:

      /**
       *@query SELECT * FROM Account WHERE id = $1
       *@handler beans(Account)
       */

      Collection getAllAccounts(int id);

    Do you see any kind of programming in this method implementation ? It is declaration only, SQL is declarative too, is not it ?
  36. iBATIS is not ORM[ Go to top ]

    Please use iBATIS if you like. I just don't think O/R is good because it throws more config files into my Java project.
    There is one very important point here: iBATIS is not an ORM. It does not bind classes to tables, nor does is it limited to OO languages and/or relational databases. But that's getting off topic...

    Like you I have my opinions and I detest code generation (whether it's Java or SQL). I don't mind XDoclet style configuration generation (like Hibernate). But that's my opinion that I won't bore you with.

    I can see now why you don't like ORM or iBATIS --you prefer code generation. That's fair.

    Cheers,
    Clinton
  37. iBATIS is not ORM[ Go to top ]

    I do not think gode generation conflicts with iBATIS or O/R frameforks, I advokate runtime code generation, but I see nothing wrong to generate source code too, I think it can be a good idea to generate code from IBATIS XML files. I do not know how inheritance can help to write data access code, but code generation is a good helper.
    I hope Race condition will explain how to use plain OOP to implement DAO and I hope this post is not fake as the author's name.
  38. no thanks[ Go to top ]

    Yes, I agree with every reason that you state. However, a well-defined DAO superclass does all of the above AND I did not have to spend any time learning specific syntax like this...
    Note that the examples in the other TSS thread that I referred to did not use iBATIS SQL Maps, but rather Spring's JDBC respectively Hibernate support. Note that Spring provides similar integration classes for a number of data access strategies: JDBC, Hibernate, JDO, Apache OJB, and iBATIS SQL Maps. You still have the choice between straight SQL-based access and O/R Mapping.

    As you noted further below, Spring's JdbcTemplate does indeed provide similar benefits as a custom JDBC DAO superclass. It does in a library fashion, though, without the need to derive your DAO from a base class, and with a few sophisticated extras. Spring's HibernateTemplate, SqlMapTemplate etc provide similar benefits for the other data access strategies.

    We're encountering an important point here: Spring's DAO support is about making the work with your chosen data access strategy easier, rather than making the actual strategy choice for you. It avoids exactly the need for custom infrastructure code like your own DAO base classes; its conciseness also avoids the need for code generation to a large degree.

    Juergen
  39. no thanks? yes please[ Go to top ]

    The Spring JDBC layer uses a feature called callback templates to pass control from your application to the framework. With this strategy, Spring removes the need to manage connections, result sets, and RDBMS-specific errors.
    We all know how difficult it is to manage a jdbc connection. Let's see...setAutoCommit(), commit(), rollback(), close().And the ResultSet! I don't know what I would do with a ResultSet. Well, I guess I could loop through it and create objects... No, sounds too risky. I better jump on the O/R Mapping bandwagon before I hurt myself.
    Mr Condition, I think your criticism is wide of the mark. The Template pattern solves the problem of repeated code in DAO methods. It is independent of O/R Mapping. I have been using the JDBCTemplate (via JDBCDaoSupport) and it means my DAO methods are simpler to implement and maintain.

    "We mock what we do not understand".
  40. no thanks? yes, none for me.[ Go to top ]

    Mr Condition, I think your criticism is wide of the mark. The Template pattern solves the problem of repeated code in DAO methods. It is independent of O/R Mapping. I have been using the JDBCTemplate (via JDBCDaoSupport) and it means my DAO methods are simpler to implement and maintain.
    Mr. Pepper,

    My DAO methods are simpler to implement and maintain as well. This is because my DAO superclass holds all of the 'repeated code' that you speak of. So the 'problem of repeated code' is not found in my code. I suspect that my DAO superclass is similar to the JDBCTemplate that you speak of.
    "We mock what we do not understand".
    No, I do understand. All that O/R tools do are replace SQL/JDBC code with configuration files. I guess the part I don't understand is why developers don't know how to write their own high-quality, super-efficient DAO framework. And don't give me that 'reinventing the wheel' argument because my DAO code has been around longer than most O/R tools.

    Cheers!
  41. No, I do understand. All that O/R tools do are replace SQL/JDBC code with configuration files.
    it seems that you have very little knowledge of o/r mapping tools. then it's better not to make public statements of that kind.
  42. No, I do understand. All that O/R tools do are replace SQL/JDBC code with configuration files.
    it seems that you have very little knowledge of o/r mapping tools. then it's better not to make public statements of that kind.
    Public statement has no value if it has no author.
  43. It's all about leverage, no?[ Go to top ]

    All of the syntax that you show has a purpose. You can surface it as configuration or code. I like Spring because, whichever style I choose, it lets me

    - choose my sword. I am not limited to the approach that you dictate. I usually recommend Hibernate for applications requiring a little more pop and good simplicity, or Kodo for a fully standardized commercial ORM, that I prefer for enterprise solutions. Or I can go to some lighter DAO-style frameworks (I firmly believe that IBatis is the best...I'll be recommending it with more frequency), or even JDBC.

    - swing it with more power. With the leverage provided by Spring, I have minimal repetition, cleaner exceptions, smoother resource management, declarative transactions with a pluggable strategy, consistent configuration strategies (XML, XDoclet style, soon Groovy), and pluggable resources like data sources. In any case, I write less code, have cleaner tests, and have better adaptability. That's leverage, regardless of the strategy that I choose. Note that only part of the power is AOP. The rest concerns good, consistent pragmatic decisions, over and over. It's really a joy to work with.

    That's the power of Spring.