Spring Roo
  1. Spring Roo
  2. ROO-301

Choose between data access patterns

    Details

    • Type: New Feature New Feature
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Complete
    • Affects Version/s: 1.1.4.RELEASE
    • Fix Version/s: 1.2.0.M1
    • Component/s: PERSISTENCE
    • Labels:
      None

      Description

      At this time, the Aspect J generated aspects and entity classes follow the Active Record pattern.

      It would be nice if we could choose between this pattern and Data Access Object, with or without Spring DaoSupport. The way to configure would be "persistence setup ... --databaseAccessPattern ActiveRecord|DAO".

      1. ICriteria.java
        0.3 kB
        Alexander Makarevitch
      2. IFilter.java
        0.2 kB
        Alexander Makarevitch
      3. Repository.java
        0.3 kB
        Alexander Makarevitch

        Issue Links

          Activity

          Hide
          Carlos Chacin added a comment -

          I agree with Andrew about new Spring Data JPA

          Show
          Carlos Chacin added a comment - I agree with Andrew about new Spring Data JPA
          Hide
          Kieran Simpson added a comment -

          Given that the Spring Data JPA project is feature equivalent to Hades; it's the right way forward.

          Show
          Kieran Simpson added a comment - Given that the Spring Data JPA project is feature equivalent to Hades; it's the right way forward.
          Hide
          Christopher Hunt added a comment -

          From my perspective I would like to see Roo offer scaffolded DTO classes (1) and DAOs. I commonly find that DTOs initially have a strong correlation with their domain model relatives. However as the project evolves the DTOs can become quite different. I often find that I end up with a small set of DTOs when compared to the domain model.

          DTOs are generally born from the requirements of DAO methods. There's a tendency to create DAO methods that merely implement CRUD. However I think that this is wrong (2). DAO methods should be driven by their service layer requirements and optimise queries to the data store for these use cases.

          Having the separation of concerns between the DTOs and domain objects also permits the domain model to evolve independently and vice versa. The "contracts" within organisations (and outside) are also often different for DTOs and the domain model.

          Having Roo be able to generate the following would be incredibly useful:
          1. a DAO with no methods
          2. a non-CRUD-like method of a DAO along with an associated DTO

          When specifying a DTO to Roo, one could initially specify the domain model object it relates to.

          Finally, DTOs should be composed of domain objects and provide a facade to them i.e. not be them.

          Thanks.

          (1) http://martinfowler.com/eaaCatalog/dataTransferObject.html
          (2) http://christopherhunt-software.blogspot.com/2011/04/dao-coding-paradigms-can-require-some.html

          Show
          Christopher Hunt added a comment - From my perspective I would like to see Roo offer scaffolded DTO classes (1) and DAOs. I commonly find that DTOs initially have a strong correlation with their domain model relatives. However as the project evolves the DTOs can become quite different. I often find that I end up with a small set of DTOs when compared to the domain model. DTOs are generally born from the requirements of DAO methods. There's a tendency to create DAO methods that merely implement CRUD. However I think that this is wrong (2). DAO methods should be driven by their service layer requirements and optimise queries to the data store for these use cases. Having the separation of concerns between the DTOs and domain objects also permits the domain model to evolve independently and vice versa. The "contracts" within organisations (and outside) are also often different for DTOs and the domain model. Having Roo be able to generate the following would be incredibly useful: 1. a DAO with no methods 2. a non-CRUD-like method of a DAO along with an associated DTO When specifying a DTO to Roo, one could initially specify the domain model object it relates to. Finally, DTOs should be composed of domain objects and provide a facade to them i.e. not be them. Thanks. (1) http://martinfowler.com/eaaCatalog/dataTransferObject.html (2) http://christopherhunt-software.blogspot.com/2011/04/dao-coding-paradigms-can-require-some.html
          Hide
          Stefan Schmidt added a comment -

          With the upcoming 1.2.0.M1 release Roo will support three types of data access patterns:

          1. 'Active Record'-style JPA persistent domain entities (default persistence provider)
          2. JPA repositories backed by Spring Data JPA (former Hades)
          3. MongoDB repositories backed by Spring Data MongoDB (see ROO-2693)

          All three persistence options are integrated through a new layer service offered by Roo. This means that other add-ons will be able to automatically wire themselves to use these repositories once they are detected in the project.

          At present a new service layer add-on, the Spring MVC add-on, the integration test and data on demand add-ons (test support for mongo repositories is not yet offered) are already integrated with the new layering support. The GWT and (to be released) JSF add-ons will follow soon.

          Documentation for all supported layers and their features will be published with the 1.2.0.M1 release.

          Show
          Stefan Schmidt added a comment - With the upcoming 1.2.0.M1 release Roo will support three types of data access patterns: 1. 'Active Record'-style JPA persistent domain entities (default persistence provider) 2. JPA repositories backed by Spring Data JPA (former Hades) 3. MongoDB repositories backed by Spring Data MongoDB (see ROO-2693 ) All three persistence options are integrated through a new layer service offered by Roo. This means that other add-ons will be able to automatically wire themselves to use these repositories once they are detected in the project. At present a new service layer add-on, the Spring MVC add-on, the integration test and data on demand add-ons (test support for mongo repositories is not yet offered) are already integrated with the new layering support. The GWT and (to be released) JSF add-ons will follow soon. Documentation for all supported layers and their features will be published with the 1.2.0.M1 release.
          Hide
          Stefan Schmidt added a comment -

          Integration test support for Spring Data MongoDB is now also available (see ROO-2700).

          Show
          Stefan Schmidt added a comment - Integration test support for Spring Data MongoDB is now also available (see ROO-2700 ).

            People

            • Assignee:
              Stefan Schmidt
              Reporter:
              Cyril Delmas
            • Votes:
              107 Vote for this issue
              Watchers:
              75 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: