Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-9118

Implement better support for a concept similar to ExternalizableBusinessObjects in the new krad-data framework

    Details

    • Type: Improvement
    • Status: Open
    • Priority: Critical
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: 2.6
    • Component/s: Analysis, JPA, Roadmap
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Rice Module:
      KRAD
    • KRAD Feature Area:
      Persistence Framework
    • Sprint:
      2.4.0-m4 Dev Sprint 4 (Real)
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required
    • Include in Release Notes?:
      Yes

      Description

      Persistence provider likely provides much of this for us from the persistence side, but we need to determine specifics on how exactly we want this to work.

      Analysis document:
      https://docs.google.com/a/kuali.org/document/d/18zvNsrC4j3aY302HtFdt7K-GRdx1KU7OBkFiIr4VIXQ/edit#

        Attachments

          Issue Links

            Activity

            Hide
            jkeller Jonathan Keller added a comment -

            I would say that DTOs are those objects provided by a non-PP service interface. (I'll take KIM as the main example of that.)

            I'd say that a "data object" is something which can be loaded from a persistence provider. It may use a DTO object to pull the information from the source, but then translate it into something which can be more easily used by the application. (There is often the assumption that you can change properties on a data object, something which is not true of our DTOs.

            This is making me think that we might want to add a "RiceServerPersistenceProvider" which is set to handle (on embedded setups) the Rice objects which we presently have as EBOs. This service would call the existing services (CountryService, etc...) to pull the data and translate back into a DO-type object.

            Show
            jkeller Jonathan Keller added a comment - I would say that DTOs are those objects provided by a non-PP service interface. (I'll take KIM as the main example of that.) I'd say that a "data object" is something which can be loaded from a persistence provider. It may use a DTO object to pull the information from the source, but then translate it into something which can be more easily used by the application. (There is often the assumption that you can change properties on a data object, something which is not true of our DTOs. This is making me think that we might want to add a "RiceServerPersistenceProvider" which is set to handle (on embedded setups) the Rice objects which we presently have as EBOs. This service would call the existing services (CountryService, etc...) to pull the data and translate back into a DO-type object.
            Hide
            jksmith James Smith added a comment -

            Okay, that makes sense too. So: James B sent me an oracle page about this which I want to read up on but to get to really the heart of why I'm curious about all of this right now: ideally, would data objects which KC wants KFS to know about be DO's or DTO's to KFS? They do both live in "persistence providers" - but what you're saying, Jonathan, is that what really matters if it's read-only or not, right? Let's say furthermore that KC wants the same DO's to be exposed to some non-Kuali application. In that case, would these be DTO's to KFS as well just to make it convenient for KC?

            Thanks for all of this information!

            Show
            jksmith James Smith added a comment - Okay, that makes sense too. So: James B sent me an oracle page about this which I want to read up on but to get to really the heart of why I'm curious about all of this right now: ideally, would data objects which KC wants KFS to know about be DO's or DTO's to KFS? They do both live in "persistence providers" - but what you're saying, Jonathan, is that what really matters if it's read-only or not, right? Let's say furthermore that KC wants the same DO's to be exposed to some non-Kuali application. In that case, would these be DTO's to KFS as well just to make it convenient for KC? Thanks for all of this information!
            Hide
            jawbenne James Bennett added a comment -

            I would think you would always want to take in and return DTOs from your service calls and leave the DO out of it completely. If your DTOs are immutable that means the client who invokes your service will not have to worry about maintaining the state in the object which is returned and it could potentially be cached.

            Show
            jawbenne James Bennett added a comment - I would think you would always want to take in and return DTOs from your service calls and leave the DO out of it completely. If your DTOs are immutable that means the client who invokes your service will not have to worry about maintaining the state in the object which is returned and it could potentially be cached.
            Hide
            ewestfal Eric Westfall added a comment -

            I would also add that there's no reason a PersistenceProvider couldn't be implemented to broker DTO's as well, services designed using DTO's tend to have CRUD-like behaviors too You could also have a PersistenceProvider that doesn't support the save and delete operations and exists solely for the purposes of querying and fetching data.

            Show
            ewestfal Eric Westfall added a comment - I would also add that there's no reason a PersistenceProvider couldn't be implemented to broker DTO's as well, services designed using DTO's tend to have CRUD-like behaviors too You could also have a PersistenceProvider that doesn't support the save and delete operations and exists solely for the purposes of querying and fetching data.
            Hide
            jkeller Jonathan Keller added a comment -

            I added some additional notes on the linked google doc.

            Show
            jkeller Jonathan Keller added a comment - I added some additional notes on the linked google doc.

              People

              • Assignee:
                Unassigned
                Reporter:
                ewestfal Eric Westfall
              • Votes:
                0 Vote for this issue
                Watchers:
                8 Start watching this issue

                Dates

                • Created:
                  Updated:

                  Time Tracking

                  Estimated:
                  Original Estimate - 3 days
                  3d
                  Remaining:
                  Remaining Estimate - 3 days
                  3d
                  Logged:
                  Time Spent - Not Specified
                  Not Specified