My last few coding projects have been very object oriented roll-your-
own business classes. I just finished an interview that went very
well, and it looks like my next project may be a dataset only shop.

Since I won't be able to roll my methods in with the datasets, what
kind of patterns can I use? Where do I put my methods that interact
with the datasets data? How can I create a business layer that models
the problem domain with datasets?

Jordan

On Jun 15, 2:08 pm, Jordan Marr <jnm> wrote:
> My last few coding projects have been very object oriented roll-your-
> own business classes. I just finished an interview that went very
> well, and it looks like my next project may be a dataset only shop.

Note that you may want to be careful not to impose your personal
coding style too quickly on a new job, especially if there are other
coders still there. Every company and department has their own style
and culture, and going against it may create friction. I would suggest
using their approach for the first 6 months or so, and when you get a
feel for how they do things, then slowly introduct your own
techniques. And, don't insult the existing techniques, you never know
whose feelings you may hurt.

Been there done that.

>
> Since I won't be able to roll my methods in with the datasets, what
> kind of patterns can I use? Where do I put my methods that interact
> with the datasets data? How can I create a business layer that models
> the problem domain with datasets?
>
> Jordan

-T-

"Jordan Marr" <jnmarr> wrote in message
news:5630
> My last few coding projects have been very object oriented roll-your-
> own business classes. I just finished an interview that went very
> well, and it looks like my next project may be a dataset only shop.

> Since I won't be able to roll my methods in with the datasets, what
> kind of patterns can I use?

You won't be using as many or should I say not the same ones you were using.
The datasets implement some of the patterns you might normally use
themselves. Others won't make sense with the dataset approach.

Where do I put my methods that interact
> with the datasets data?

You can have objects that you pass the datasets into and then the methods
use the datasets for the data.

How can I create a business layer that models
> the problem domain with datasets?

You don't really. The dataset centric approach and the domain model approach
are different beasts.

Martin Fowler has some examples in Patterns of Enterprise Application
Architecture. See Table Module and Recordset sections.

> Jordan

Best of Luck.

PS

"Jordan Marr" <jnmarr> wrote in message
news:5630
> My last few coding projects have been very object oriented roll-your-
> own business classes. I just finished an interview that went very
> well, and it looks like my next project may be a dataset only shop.
>
> Since I won't be able to roll my methods in with the datasets, what
> kind of patterns can I use? Where do I put my methods that interact
> with the datasets data? How can I create a business layer that models
> the problem domain with datasets?
>
> Jordan
>

Here is someone's rant about PoEAA and the datasets vs domain model which is
worth reading for the first couple of paragraphs.

http://unboxedsolutions.com/sean/arc...10/12/322.aspx

Responding to Marr...

> My last few coding projects have been very object oriented roll-your-
> own business classes. I just finished an interview that went very
> well, and it looks like my next project may be a dataset only shop.
>
> Since I won't be able to roll my methods in with the datasets, what
> kind of patterns can I use? Where do I put my methods that interact
> with the datasets data? How can I create a business layer that models
> the problem domain with datasets?

My guess is that the short answer is: You don't.

If the shop is emphasizing datasets that much it is probably developing
CRUD/USER software where the applications are pipelines between the RDB
and the UI. In that sort of environment the RAD view dominates and there
are plenty of layered model infrastructures that do a lot of the grunt
work. Those infrastructures will be, at most, object-based and they make
wide-spread use of techniques like composition that one would rarely see
in an OO environment.

The point is that for that sort of processing the RAD paradigm is the
best practical fit and attempting to use standard OOA/D techniques would
be overkill at best or would just get in the way at worst. IOW: when in
Rome do as the Romans do.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

On Jun 16, 1:48 am, "PS" <ecneserpeg> wrote:
[..]
> You don't really. The dataset centric approach and the domain model approach
> are different beasts.
>
> Martin Fowler has some examples in Patterns of Enterprise Application
> Architecture. See Table Module and Recordset sections.
>> Best of Luck.
>
> PS

Thanks. I have that book and have read those patterns.

So I would a "service layer" that accepts the dataset objects and acts
upon them?

Jordan

> Note that you may want to be careful not to impose your personal
> coding style too quickly on a new job, especially if there are other
> coders still there. Every company and department has their own style
> and culture, and going against it may create friction. I would suggest
> using their approach for the first 6 months or so, and when you get a
> feel for how they do things, then slowly introduct your own
> techniques. And, don't insult the existing techniques, you never know
> whose feelings you may hurt.
>
> Been there done that.

This is sound advice. I do tread carefully.

Jordan

> If the shop is emphasizing datasets that much it is probably developing
> CRUD/USER software where the applications are pipelines between the RDB
> and the UI. In that sort of environment the RAD view dominates and there
> are plenty of layered model infrastructures that do a lot of the grunt
> work. Those infrastructures will be, at most, object-based and they make
> wide-spread use of techniques like composition that one would rarely see
> in an OO environment.

Why do you say that composition is rarely seen in an OO environment?

>
> The point is that for that sort of processing the RAD paradigm is the
> best practical fit and attempting to use standard OOA/D techniques would
> be overkill at best or would just get in the way at worst. IOW: when in
> Rome do as the Romans do.

Yes, I agree.

Jordan

Responding to Marr...

>>If the shop is emphasizing datasets that much it is probably developing
>>CRUD/USER software where the applications are pipelines between the RDB
>>and the UI. In that sort of environment the RAD view dominates and there
>>are plenty of layered model infrastructures that do a lot of the grunt
>>work. Those infrastructures will be, at most, object-based and they make
>>wide-spread use of techniques like composition that one would rarely see
>>in an OO environment.
>> Why do you say that composition is rarely seen in an OO environment?

I was imprecise; I should have said it is rarely seen in well-formed OO
applications. Also, to clarify, in this context the composition I am
talking about is essentially multiple inheritance or using
generalization to provide a mapping across layer interfaces where the
superclass provides mapping implementations.

The problem with composition in an OO environment is that it tends to
trash cohesion. When an object inherits different properties from
different generalization superclasses, those properties tend to be
disparate. Then the resulting object is a hybrid with clumps of
properties that are unrelated.

[One gets the same effect with single generalizations when the tree is
large. Since every subclass object is-a member of the root superclass,
the resulting plethora of specialized subclass properties applies to the
superset as a union of subsets. That union of disparate properties tends
to trash the superset cohesion. So we usually employ delegation to avoid
large generalizations.]

There are situations where composition is harmless because the
properties being composed are already logically related to the object's
intrinsic properties in the problem space. But those are fairly rare and
there is a huge amount of abuse. One of the more common abuses is the
-able compositions (persistable, displayable, streamable, etc.). This
tends to lead to hybrid objects that do not have any counterpart
entities in the problem space. For example, try going into you local car
dealer and asking to see a Displayable Jeep Cherokee. B-)

The reason we want to maintain accurate mapping to the problem space is
for long-term stability. Customers don't like change any more than
software developers do. When the problem space changes the customer will
tend to accommodate that change in a manner that causes minimal
disruption to the customer's existing infrastructure. When those changes
filter down to the software, they are less likely to be disruptive if
the software structure faithfully reproduces the customer's problem
space structure. That's because the customer has already figured out the
path of least resistance.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH

> > Why do you say that composition is rarely seen in an OO environment?

> I was imprecise; I should have said it is rarely seen in well-formed OO
> applications. Also, to clarify, in this context the composition I am
> talking about is essentially multiple inheritance or using
> generalization to provide a mapping across layer interfaces where the
> superclass provides mapping implementations.

> The problem with composition in an OO environment is that it tends to
> trash cohesion. When an object inherits different properties from
> different generalization superclasses, those properties tend to be
> disparate. Then the resulting object is a hybrid with clumps of
> properties that are unrelated.

Interesting. I currently code in C# which excludes multiple
inheritance as a feature. I imagine they avoided including this
feature so they wouldn't have to deal with cases where an object
inherits from two different classes with the same methods, but that is
just my own speculation. The problem you mentioned of an object
having dual purposes because of multiple inheritance is also avoided
in this case. (As opposed to the idea that an object should have one
clearly defined purpose).

When I think of composition, I think of adding another class as a
private member to the new class, and then creating public functions on
the new class that delegate the call to the private member -- like the
State Pattern.


> There are situations where composition is harmless because the
> properties being composed are already logically related to the object's
> intrinsic properties in the problem space. But those are fairly rare and
> there is a huge amount of abuse. One of the more common abuses is the
> -able compositions (persistable, displayable, streamable, etc.). This
> tends to lead to hybrid objects that do not have any counterpart
> entities in the problem space. For example, try going into you local car
> dealer and asking to see a Displayable Jeep Cherokee. B-)

Displayable would be more appropriate as an interface, correct?

> The reason we want to maintain accurate mapping to the problem space is
> for long-term stability. Customers don't like change any more than
> software developers do. When the problem space changes the customer will
> tend to accommodate that change in a manner that causes minimal
> disruption to the customer's existing infrastructure. When those changes
> filter down to the software, they are less likely to be disruptive if
> the software structure faithfully reproduces the customer's problem
> space structure. That's because the customer has already figured out the
> path of least resistance.

This is a good point in favor of modeling the problem space!

Thanks for sharing your knowledge. Your posts always require me to
stretch my mind.

Jordan

"Jordan Marr" <jnmarr> wrote in message
news:0820
> On Jun 16, 1:48 am, "PS" <ecneserpeg> wrote:
>
> Thanks. I have that book and have read those patterns.
>
> So I would a "service layer" that accepts the dataset objects and acts
> upon them?

I have moved away from using datasets for almost 3 years so I am not the
person to ask about how to work with them. PoEAA is probably the only book
that I have on my bookshelf that has examples of using them so I would
follow Fowlers suggestion of what patterns go together unless you can find a
better authority on the subject!!

PS

Responding to Marr...

>> Interesting. I currently code in C# which excludes multiple
> inheritance as a feature. I imagine they avoided including this
> feature so they wouldn't have to deal with cases where an object
> inherits from two different classes with the same methods, but that is
> just my own speculation. The problem you mentioned of an object
> having dual purposes because of multiple inheritance is also avoided
> in this case. (As opposed to the idea that an object should have one
> clearly defined purpose).

IMO C# is going overboard in the other direction. There are situations
where MI is useful. One just has to be disciplined about using it so
that cohesion isn't broken.

> When I think of composition, I think of adding another class as a
> private member to the new class, and then creating public functions on
> the new class that delegate the call to the private member -- like the
> State Pattern.

This is a somewhat different issue. We do that sort of thing all the
time with computing space ADTs like String and Array.

However, I am not keen on doing that with problem space objects. It can
be justified when there is a Whole/Part relationship in the problem
space because the life cycles are tied together (i.e. a UML composition
association). However, even then I would be reluctant to do it if any of
the Part's responsibilities need to be exposed to other objects to solve
the problem.

The problem is that to expose its properties externally, one has to
define those responsibilities as public properties of the Whole. But
they aren't really the container's properties in the problem space. If
one needed that sort of delegation to identify the Part to solve the
problem, the responsibility now belongs to the Part.

IOW, at the level of abstraction where one needs broader access to the
Part properties, the Whole and Part are peer objects with their own
unique identity in the problem. Whoever needs to collaborate with the
Part properties should be talking to Part.

>>There are situations where composition is harmless because the
>>properties being composed are already logically related to the object's
>>intrinsic properties in the problem space. But those are fairly rare and
>>there is a huge amount of abuse. One of the more common abuses is the
>>-able compositions (persistable, displayable, streamable, etc.). This
>>tends to lead to hybrid objects that do not have any counterpart
>>entities in the problem space. For example, try going into you local car
>>dealer and asking to see a Displayable Jeep Cherokee. B-)
>> Displayable would be more appropriate as an interface, correct?

But the Displayable superclass is defining responsibilities that the
Jeep Cherokee object must implement and is now expected to provide. If
it were a simple interface, then it could only expose properties that
the Jeep Cherokee object intrinsically had.

>>The reason we want to maintain accurate mapping to the problem space is
>>for long-term stability. Customers don't like change any more than
>>software developers do. When the problem space changes the customer will
>>tend to accommodate that change in a manner that causes minimal
>>disruption to the customer's existing infrastructure. When those changes
>>filter down to the software, they are less likely to be disruptive if
>>the software structure faithfully reproduces the customer's problem
>>space structure. That's because the customer has already figured out the
>>path of least resistance.
>> This is a good point in favor of modeling the problem space!

The vast majority of "shotgun refactorings" where lots of objects are
touched to make a single change are due to architectural drift of the
software structure away from the customer space structure. The
refactorings are primarily just getting the software structure back to
the point of emulating the problem space where it should have been in
the first place.

Alas, architectural drift is a serious problem at the OOP level. Because
of physical coupling in the OOPLs one /needs/ to employ dependency
management refactoring to make the code more maintainable and that is
largely orthogonal to solving the customer's problem. So as one moves
responsibilities around, creates abstract classes, and provides lots of
wrappers to reduce physical coupling, one runs the risk of drifting away
from the original problem space structure.

> Your posts always require me to stretch my mind.

I hate it when that happens. A couple of ibuprofen usually work for me,
though.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH