Announcement Announcement Module
Collapse
No announcement yet.
StoredProcedures and RowMappers as Spring Beans Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • StoredProcedures and RowMappers as Spring Beans

    Hi All,
    Iím on the fence regarding how my Dao layer should get references to StoredProcedures and RowMappers and Iím looking for someone to push me off the fence 
    I have some Dao classes that make use of a lot of StoredProcedure implementations and also RowMapper instances. The two approaches Iím weighing are as follows:


    A) Spring Managed Bean Approach
    - Define the SPs and corresponding RowMappers as managed beans and wire/inject them into my Dao layer.

    B) Instantiate at DataSource setter time
    - Iíve seen a lot of spring jdbc code examples where rather than configuring a JdbcTemplate instance in the Application Context and injecting it into a DAO, you just inject a DataSource instance and ďnewĒ a JdbcTemplate using the supplied DataSource. Being that the abstract StoredProcedure class also accepts a DataSource instance as a constructor argument, Iím thinking this might be an acceptable approach for creating StoredProcedure instances too?

    As for the RowMapper question, is it overkill to define RowMapper instances as managed beans in the application context? Most of the examples Iíve seen of mapper classes are implemented as static inner classes and new instances are passed where needed. It seems that the number of places that the mappers are used factors into the decision. In my case, there are about 20 mappers and about a third of them are used in multiple places. Any opinions on which is the better approach?

    Any feedback/discussion would be appreciated.
    Thanks in advance!

  • #2
    i think approach A is not much better ,,, as it will be heavy loading on Application Context if you define all rowmapper and all.

    So i will suggest for approach B,,, and if you wish you can inject SP instances as well in DAO classes along with DataSource,,which is ultimately used by SP only. but again to inject RowMapper is not much advisable...

    As you have already seen many examples or may be developed also, so not to mention example for you. But in case whoever read this thread can be benefited.. so just adding my comments how i have implemented it.

    In my application we have service classbean, where we are injecting DAO bean, and in DAO bean we are injecting DataSource,,,and from DAO claass we call SPs and pass the DataSource over there and under SP we have RowMapper which iterate through ResultSet and returns results. So ApplicationContext.xml will not have SP class/Row Mapper class definds as Managed Bean. But service class/ DAO class and DataSouce will be managed by spring container.

    Hope i have put my comments in correct directions only. please describe your questions so other can reply with proper suggestions....

    Comment


    • #3
      Stored procedures are special objects available in sql server. Its a precompiled statements where all the preliminary parsing operations are performed and the statements are ready for execution.

      Its very fast when compared to ordinary sql statements where the sql statements will undergone a sequence of steps to fetch the data

      Stored procedure involves various syntax based on the parameters passed. Let me show you a generic syntax for a stored procedure.
      SEO Next

      Comment


      • #4
        Yep,, i knw store procedures very well,, we call sprocs from ProcedureXXX.java class which extends org.springframework.jdbc.object.StoredProcedure ...

        And in ProcedureXXX.java class we pass actual sproc name and over there we have RowMapper also defined....

        Comment


        • #5
          Thank you for the replies. I am also leaning towards option B because I don't see a *huge* benefit to defining sprocs in the app context. These sprocs aren't like other beans where we're defining a service *interface* and then using the IOC container to inject a particular implementation of that interface. It's funny, I think this is a case where the framework made it *too* easy to define beans and inject them into other classes because, in the case of defining/injecting row mappers, it almost seems like misuse of the framework. Even though it's very easy to do so, I'm sure there's a bit of overhead for each bean that's defined in the app context. It's my hunch that this mostly comes into play at app context start up time though. Can somebody who is more familiar with the innerds of the framework speak to the downsides of getting "bean crazy"

          Thanks again for any replies!

          Comment

          Working...
          X