SOA Design Question

Of course, the real answer is that you haven't given us enough information ... but, there are a couple of things one might say.

In an OERA design, the "table" is visible only to the data access layer, so the rest of the application will be dealing in terms of "objects". Whether or not these are true .cls based object or .p files acting like objects, they will encapsulate data and behavior in a way that there is no necessary link to how this data is stored.

So, the real answer to your question depends on what the system is about. If the system is about cars, e.g., who is authorized or who has some historical connection to which car, then one is likely to create a car object and one of the properties of that car object will be the drivers associated with that car. If the system is about people and which cars are associated with those people, then one would probably do the reverse.

Note that in both cases the relational design of needing to support a many to many join disappears since one can simply have a property of a car which is a list of people or a property of a person which is a list of cars. The data access layer would need to fold and unfold that into the three tables.

John Sadd might come along here and point out that one might want to do some reporting which involved a group of cars and a group of people and this was an argument for carrying forward the three table design into the business layer, but I'm not sure that the requirement is actually that vague. The three table approach is great for generality, but in any specific case one is likely to "know something" about the domain (which you haven't told us anything about). Depending on the characteristics of that domain, one might use a number of data structures including a simple collection of objects of whatever the primary type might be.

In fact, if the domain was about rental cars, one might actually have a rental agreement object which contained one or more driver objects and one car object. This object would effectively correspond to the join table, not to either "primary" table.

Enough speculation!

Well, I didn't have any specific domain in mind when I posted the question. I was just thinking in generic terms of having two very clearly defined business entities (Cars and Drivers), and started to wonder in which DAO (daCars or daDrivers, as you point out) the CarDrivers table should be accessed/updated, supposing the presentation layer might need to expose cars by drivers sometimes and drivers by cars in other cases.

I suspect this isn't enough information either,...:)

I suspect this isn't enough information either,...:)

Correct. In fact, the answer might well be both. When constructing a car object ... hopefully not daCar.p* ... you may have a need to list the drivers associated with that car and, vice versa, in the driver object you might have a need to list the cars associated with that driver. This would mean that all three tables were accessed in both object's data access layer.

• I dislike the prefix approach to naming for these objects because it means that the related objects are separated by name. Frankly, I would rather put all of the car related files into its own subdirectory anyway. My current nomenclature is running toward Car.cls for the domain object, CarFinder.cls for the object that specifies which car(s) are going to be retrieved and managed, and CarMapper.cls for the object that does the object-relational mapping.

I dislike the prefix approach to naming for these objects because it means that the related objects are separated by name.

Not sure I understand what you mean here, you are saying beCar.p and daCar.p are related to Car but start with a different prefix?

My current nomenclature is running toward Car.cls for the domain object, CarFinder.cls for the object that specifies which car(s) are going to be retrieved and managed, and CarMapper.cls for the object that does the object-relational mapping.

In analogy to your beloved .p's I understand Car.cls replaces beCar.p and CarFinder.cls is the daCar.p. Is this correct? I can't see the exact purpose of CarMapper.cls, could you give an example of it's functionality?

Thanks.

Not sure I understand what you mean here, you are saying beCar.p and daCar.p are related to Car but start with a different prefix?

Yes, which means they don't group together in any file listing.

In analogy to your beloved .p's I understand Car.cls replaces beCar.p and CarFinder.cls is the daCar.p. Is this correct? I can't see the exact purpose of CarMapper.cls, could you give an example of it's functionality?

No, this isn't a straight correspondence. I don't yet have a class corresponding to the data source object ... I am still considering whether it is necessary or useful. The Finder is a facade that provides the interface to the business logic layer. Each component of the business logic that needs a Car will instantiate its own Finder and provide it with selection criteria for one or a group of Car. Finder connects to an single shared instance of Mapper which does the actual retrieval from the database. If you are in the beta program, there is sample code posted in the beta forum which I will publish openly after FCS.

When constructing a car object you may have a need to list the drivers

associated with that car and, vice versa, in the

driver object you might have a need to list the cars

associated with that driver. This would mean that

all three tables were accessed in both object's data

access layer.

Yes, this seems perfectly reasonable. In general it is advisable that a given piece of data (a field in the case of a traditional database) is updatable only from one object in the application, so that its support logic doesn't get duplicated unnecessarily. So even maintaining a strictly relational view of this data, your Car object could have a Car table and a related table of Drivers (of that Car), and the Driver object would have a Driver table and a related table of Cars (which that Driver had driven). These would be built (in the FILL) using the xref table that connects them, but the resulting DataSet would express only one direction or the other of the relationship. And the Driver data wouldn't be modifiable via the Car object, and vice versa. Updating the common xref table via either object (to add an existing Driver to a Car or vice versa) is a (seemingly small) exception to the rule of updating only in one place.

• I dislike the prefix approach to naming for these

objects because it means that the related objects are

separated by name.

Good point, Also, as the creator of this particular naming convention, I can't help noting the possibly unfortunate comparisons to daAliGShow....

Our real problem here is that we have no real definition of the domain other than cars and drivers. In some domains, a single point of update may be appropriate because there is a primary object. In others, the association may be far more loose and it will be appropriate to provide update through two or more paths.

I disagree with this. If we're saying each data item has only one place to be updated, and that place is the only place it's "logic" should go, then we're saying no matter how many functions our applications have, we have to pull out of each function the logic of each data item.

My Accounting app has a G/L Account Balance in it, and I don't think it's right to have all of my AP, AR, and GL logic related to the posting from each of those modules in one single object all tied to the data field. Not only would I not suggest pulling out each of those pieces of logic to consolidate them in a single object, I don't suggest pulling out all of the logic of one table into a single object either.

Logic is grouped together by its functionality, not the data it has to work on. Business processes determine that. We shouldn't be pulling apart functions to "enter Cash" or "make a Check" just because they both affect some of the same fields in our database.

I'm not exactly sure which point(s) you are disagreeing with here, but I hope that there aren't many people advocating the kind of lumping to which you refer ... except for a well know OO consultant (not ABL) who used to suggest, among other things, that every Item should know how to order itself.

In particular, it seems reasonable that a GLAccountBalance is updated via a GLLedgerEntry and that the various subsystems would create GLLedgerEntry objects as a part of their interface process, so, no, one wouldn't expect the GLAccountBalance to know anything about those subsystems. (Although I suspect it is something more like GLAccount:Balance).

I would say yes, and no. Certainly, there is logic associated with workflow and processes which doesn't belong in domain objects. Indeed, my preference, if possible, would be to remove this logic to a workflow engine. But, there is certainly logic associated with the domain object as well, logic common to all places that domain object is used.

Logic is grouped together by its functionality, not

the data it has to work on.

Logic is grouped by its responsibility, it encapsulates the data it needs to do its job