Model-Set-Entity Pattern - Forum - OpenEdge Development - Progress Community
 Forum

Model-Set-Entity Pattern

  • Recently I have been having private exchanges with a small number of individuals on several aspects of OO best practices using ABL and I wanted to begin making the content of some of those offline conversations public.  An area which has received a good deal of attention in those exchanges has been object-relational mapping (ORM) and how that may be achieved using OO ABL.  For many years now, the power of the ABL has been centered around managing relational data.  So a central question that has risen since the introduction of OO capabilities into the ABL: how to apply OO principles and best practices in developing data-centric OLTP-style business applications without relinquishing the power of the ABL to manage relational data.  Progress Professional Services (PPS) in North America has been using a foundation framework of components, tools, best practices called Cloudpoint. This foundation framework has its own approach to ORM called the Model-Set-Entity pattern.  I have included a high-level class diagram of Model-Set-Entity below.

    ModelSetEntity.JPG

    The diagram does not explain everything about Model-Set-Entity nor is it able to depict the whole solution to ORM,  so hopefully there will be a lot of questions and discussions forthcoming.  To the guys who I have been conversing with offline, I would ask you to keep all the detail that we have already shared to yourselves and stay more in the background on this thread until everyone else has caught up to your level. I am very interested in getting questions and opinions from the people who have not yet had the opportunity to discuss this subject.

    Phil

  • The image is not visible to me.

  • It's just the way that the communities platform manages images.  Just click on the image itself and a clear, full-size image will appear in a popup.

  • It works for me in opera, but not Firefox or IE.

  • Great stuff !

    Some questions.

    1) Why is there a bidirectionnal arrow between OrdersModel and DataAccessController ? Does DataAccessController has knowledge of OrdersModel (meaning EACH different models) ? Or it should be instead an arrow from OrdersModel to DataAccessController, and another arrow from DataAccessController to IBusinessModel ?

    2) What is the Refresh method in IEntitySet used for ?

    3) In IBusinessEntity, are the Revert() and Update() method used for Accept and Reject changes on the temp-table ?

    4) Could you show an example of what kind of steps are required for a consumer to fill an Order model from persistence ? It is not clear to me how the IBusinessModel interface is used for this purpose.

    Since the devil is in the detail, here are some more questions about the implementation:

    1) How have you implemented your Set classes ? Don't you have a base class for Sets ?

    2) How is the performance of filling this model from persistence ? Let's say for example 1000 orders, each with 100 order lines.

    3) To create a simple Order/Order Line model, 5 classes are required, right ? This seems quite some work, and this work will be repeated many times for each different model. How is the productivity of creating and working with this pattern ? Is there any class generator in the plans for helping this ?

  • Does a consumer have direct access to Order and OrderLine business entities and sets, or everything must go through the OrderModel ?

  • Hi Guillaume,

    I have a full day day today so I will address those questions which can be answered quickly and I will provide fuller answers to the others after hours.

    1) Why is there a bidirectionnal arrow between OrdersModel and DataAccessController ? Does DataAccessController has knowledge of OrdersModel (meaning EACH different models) ? Or it should be instead an arrow from OrdersModel to DataAccessController, and another arrow from DataAccessController to IBusinessModel ?

    The diagram should represent it more as a flow than a relationship.

    2) What is the Refresh method in IEntitySet used for ?

    3) In IBusinessEntity, are the Revert() and Update() method used for Accept and Reject changes on the temp-table ?

    Not exactly. But close enough.

    4) Could you show an example of what kind of steps are required for a consumer to fill an Order model from persistence ? It is not clear to me how the IBusinessModel interface is used for this purpose.

    Later.

    Since the devil is in the detail, here are some more questions about the implementation:

    1) How have you implemented your Set classes ? Don't you have a base class for Sets ?

    Base classes for sets

    2) How is the performance of filling this model from persistence ? Let's say for example 1000 orders, each with 100 order lines.

    Is your orders scenario using direct db access? Or prodatasets and temp tables?

    3) To create a simple Order/Order Line model, 5 classes are required, right ? This seems quite some work, and this work will be repeated many times for each different model. How is the productivity of creating and working with this pattern ? Is there any class generator in the plans for helping this ?

    We use UML/MDA to generate these classes.

    I will address your questions more thoroughly tonight.

    Phil

  • Direct access. The consumer uses the factory methods in the model to create entity sets.  The consumer then uses the methods on the sets to create/access entities.

  • 2) How is the performance of filling this model from persistence ? Let's say for example 1000 orders, each with 100 order lines.

    Is your orders scenario using direct db access? Or prodatasets and temp tables?

    I meant fill the whole model (dataset and set classes) from the database.

  • Ok, so the DataAccessController:GetModel() returns an OrdersModel with a filled dataset. Then we ask the OrdersModel to create its Entity sets, which is done using the dataset data ?

    The consumer then uses the methods on the sets to create/access entities.

    The Sets are created empty and they are responsible to fill themself ?

  • In the IBusinessModel definition, is IEntity vs IBusinessEntity a typo, or it's really two different interfaces ?

  • guilmori wrote:

    Ok, so the DataAccessController:GetModel() returns an OrdersModel with a filled dataset. Then we ask the OrdersModel to create its Entity sets, which is done using the dataset data ?

    Yes.  The DAController returns a model with a filled dataset.  Also, an existing model instance can be submitted to populate/repopulate its dataset.  Then the consumer (a business task typically implemented as a command class object) will call the a factory method on the model to create the entity set needed for the task.

    guilmori wrote:

    The consumer then uses the methods on the sets to create/access entities.

    The Sets are created empty and they are responsible to fill themself ?

    Yes, the sets are empty.  The set is similar to an iterator pattern - it does not encapsulate created entities.  Rather entities are only created when the consumer actually asks for one by calling a factory method to return one.

  • Thanks for catching that.  It was originally IEntity and then changed to IBusinessEntity.  The old reference must be lingering around in the UML project.  I'll fix.

  • guilmori wrote:

    2) How is the performance of filling this model from persistence ? Let's say for example 1000 orders, each with 100 order lines.

    Is your orders scenario using direct db access? Or prodatasets and temp tables?

    I meant fill the whole model (dataset and set classes) from the database.

    The model encapsulates a dataset so it would just be the time required to populate 2 related temp-tables (Orders & Orderlines) in a prodataset with 1000 orders each with 100 order lines.  Sets are not created during the fill.  They are only created when the consumer asks for them.

  • Do you mean the Entity instances aren't stored anywhere in the model ? They aren't contained by the Sets, only returned to consumer ?