Hi,
I'm reading Mike's document to get a better understanding of oera. Maybe I do not understand the piece of text below my sig. Say I have a form with a grid for orders, and a column with the name of the customer. I would get this name from the customertable, and add it in daOrder to daOrder's dataset.
Say I have a viewer in the same form for the current order, and a possibility to update the customer. For that I have a lookup with custid updatable and
custname read-only. My intuition says that if I want to get a custname after refreshing the custid, I should do this by calling a (very reusable) method in beCustomer. This beCustomer should get it's dataset from it's daCustomer. If I understand the document right that is the wrong way. I do not understand the cons described in the pdf for the usecase I described. And I do see an extra complicated architecture with an extra bt in this case.
--
Kind regards,
Stefan Houtzager
Houtzager ICT consultancy & development
http://communities.progress.com/pcom/docs/DOC-80008.
"A Business Entity cannot access another Business Entity and it cannot
access any other component of the Business Component layer. This has
specific consequences, namely that if an incoming service request
requires more than one Business Entity to successfully complete, then
the service that is publically available should not be exposed from a
Business Entity, but in fact from a Business Task or Business
Workflow. This decision removes the possibility of creating an
internal accidental call architecture where Business Entities have
built in dependencies between them, which would greatly reduce their
potential for re-use, and instead raises the orchestration of Business
Entity to Business Entity communication to a level higher. For
example, in an Order processing application there will be a
requirement to deal with Customers, Orders and Items this makes a good
candidate for a Business Task or Business Workflow as it involves
multiple Business Entities (Customer, Order and Item). In certain
situations it may be desirable to have a more combined view of data,
such as an Order containing both the Order Header and Order Line
details, along with the various ship-to and bill-to addresses of a
Customer. Whilst certainly a reasonable thing to do, it would be wise
to consider what specific business logic would be included in such a
combined Business Entity, as you do not want to duplicate business
logic in this combined entity and in the single entities such as
Order, Order Line and Customer."
Hi Stefan
I agree with your point, yes I would expect to call a "very useable" as you put it, routine in the beCustomer for the situation you describe. The point of the text you highlight below is really about separation of concern, and it trying to point out the fact that if you have a lot of interdependencies bewteen BE's then you limit their re-usability and can find yourself getting into a situation where you have a big spaghetti ball of code, with BE's calling BE's, calling BE's. So rather than building those interdependencies into the BE, it's better to raise that up to the Business Task or Workflow level, so they can perform the co-ordination between the individual BE's.
Also, don't forget the papers paint an ideal view of the world, and it's prefectly acceptable to break these guidlines, because they are just that guidelines, not rules written in stone
HTH
Mike
Maybe I do not understand the piece of text below my sig
Or, maybe you do understand it and don't agree with it as written ...
Say I have a form
Perhaps it is a bias of mine, but I think these things are easier to figure out if one takes a context that does not have UI. This isn't to say that some of the same issues might exist in a UI context and need to be addressed there, but UI can be so many different things ... including not ABL ... and it seems much easier to get oneself wrapped into knots related to *how* do I accomplish something, especially since there is often a history of how one has been accomplishing that thing in procedural code which contaminates one's thinking.
I think there are a couple of problems here which help to create a lot of confusion. One of these is the PSC "style" of having adopted PDS as containers for data which are passed between layers. It isn't terribly surprising that they did this since there is a long history pre-OO of doing this and it seems to reinforce the strengths of the ABL in relational data handling. But, in introduces some patterns which differ significantly from standard OOAD practice. While I am one of those who regularly remind people that they need to realize there are difference one should expect in OOAD patterns and solutions because one is working in a 4GL, one also shouldn't ignore a deep history of OOAD practice lightly.
In the PSC model, entities are coordinated by tasks. This is a good concept in that it emphasizes the need for task classes to manage a task context. And, of course, it avoids the kind of circular dependency problem which Mike refers to ... but so does good analysis. This kind of absolute separation is just not something one finds in traditional OOAD and I think there is a good reason for it which I will get to in a moment.
In the PSC model, the data of an entity is encapsulated in a PDS, this PDS is created by a DA component, and it is passed to a BE component which is like a hollow shell of logic to which one attaches the data. Aside from issues like the loss of encapsulation that results from the PDS definition needing to be known in multiple places, this is quite different from the structure one finds in traditional OOAD. There, the DA layer component is a machine for converting persisted data, i.e., from the RDBMS into an entity object and vice versa. The entity object encapsulates both data and behavior and is passed to and from the BL for use.
Any given entity object may have relationships with other entity objects, e.g., a Course object might have many to many relationship to Student objects where the relationship was IsEnrolledIn. That relationship exists between the objects independent of the current task. That relationship is identified in analysis and I believe should be reflected in design.
To me, the Task is there to contain the logic which is outside of that associated with the relationship itself. I.e., if the relationship is Course and Student, then there might be an Enroll task which knows about checking prerequistes, good standing of student, etc. which is not inherent to the relationship ... since exceptions might be possible.
The other factor which might be considered here is that I think there are reasons one might design "heavier" classes in ABL than in a 3GL and in some cases this will mean that a single class contains what would be a header class and a collection of child classes in a 3GL. But, that is another discussion.
Thomas wrote :
"To me, the Task is there to contain the logic which is outside of that associated with the relationship itself. I.e., if the relationship is Course and Student, then there might be an Enroll task which knows about checking prerequistes, good standing of student, etc. which is not inherent to the relationship ... since exceptions might be possible."
Which to me sounds like we're on the same page, it's all about seperation of concern. Now, how you physically implement that, be it a hybrid Data & OO model, or a more pure OO model is down to you and the situation you find yourself in, both from an application point of view as well as a skillset point of view. As I've said all along, there is no right or wrong in any of this, just what's right for you, and what works for you. Have most, if not all the examples we've provided so far followed on a general theme, sure, but that doesn't preclude any other approach. Hopefully you'll see more samples & examples in the future that explorer the other paths too!!
The main thing is we're discussing it, and that can only be a good thing!
Thanks for your reaction Mike,
There were more programmers confused about this on the peg. Overall I'm very content with your documents, you write clear language. A couple more thought-experiments here and there, as Popper would say trying to falsify your theory, would result in a progressing oera-theory.
Cheers, Stefan.
Thanks Stefan, I'm glad you find the content useful, or at least a basis for discussion.
I'm all for challenging the work we put out, because like you I agree it can only improve for everyone by community feedback and refinement.