[GOOS] Circumventing ORM Framework Limitations in GOOS Style Applications

[ACP]

Assume you have a legacy application that uses an ORM framework such as
Hibernate or another JPA application and a relational database that you
can't easily replace. You've read GOOS and want to follow the GOOS style
for new features and redesigning small parts of the existing code as time
allows. You're creating classes whose objects must be persisted. The
internal design of a typical new class contains a few attributes that must
be persisted and one or more non-persistable collaborators (e.g., some
strategy subclass or interface implementation or a listener
implementation). The ORM doesn't make life easy when you want to
reconstitute an object of such a class. Sure, the attributes are easily
mapped from the row to the object, but not so with non-persistable items.

What do you do? Do you ditch the ORM?

[Matteo Vaccari]

Not sure what it is that you find difficult. Could you move the code that
reconstitute an object to a repository object?

Post by ACP
Assume you have a legacy application that uses an ORM framework such as
Hibernate or another JPA application and a relational database that you
can't easily replace. You've read GOOS and want to follow the GOOS style
for new features and redesigning small parts of the existing code as time
allows. You're creating classes whose objects must be persisted. The
internal design of a typical new class contains a few attributes that must
be persisted and one or more non-persistable collaborators (e.g., some
strategy subclass or interface implementation or a listener
implementation). The ORM doesn't make life easy when you want to
reconstitute an object of such a class. Sure, the attributes are easily
mapped from the row to the object, but not so with non-persistable items.
What do you do? Do you ditch the ORM?
--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Matteo Vaccari]

Like, for example:

class FooRepository { // yes I know, not a good name
@Autowired EntityManager entityManager;

Foo find(FooId fooId) {
Foo foo = entityManager.find(fooId);
foo.setStrategy(new MyStrategy());
return foo;
}
}

Post by Matteo Vaccari
Not sure what it is that you find difficult. Could you move the code that
reconstitute an object to a repository object?

Post by ACP
Assume you have a legacy application that uses an ORM framework such as
Hibernate or another JPA application and a relational database that you
can't easily replace. You've read GOOS and want to follow the GOOS style
for new features and redesigning small parts of the existing code as time
allows. You're creating classes whose objects must be persisted. The
internal design of a typical new class contains a few attributes that must
be persisted and one or more non-persistable collaborators (e.g., some
strategy subclass or interface implementation or a listener
implementation). The ORM doesn't make life easy when you want to
reconstitute an object of such a class. Sure, the attributes are easily
mapped from the row to the object, but not so with non-persistable items.
What do you do? Do you ditch the ORM?
--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Christopher Gardner]

What if there are several strategies? How would the repository know which
one to set? I suppose you could add some attribute to indicate which to
use. That does throw a bit of blight on the class though.

Post by Matteo Vaccari
class FooRepository { // yes I know, not a good name
@Autowired EntityManager entityManager;
Foo find(FooId fooId) {
Foo foo = entityManager.find(fooId);
foo.setStrategy(new MyStrategy());
return foo;
}
}

Post by Matteo Vaccari
Not sure what it is that you find difficult. Could you move the code that
reconstitute an object to a repository object?

Post by ACP
Assume you have a legacy application that uses an ORM framework such as
Hibernate or another JPA application and a relational database that you
can't easily replace. You've read GOOS and want to follow the GOOS style
for new features and redesigning small parts of the existing code as time
allows. You're creating classes whose objects must be persisted. The
internal design of a typical new class contains a few attributes that must
be persisted and one or more non-persistable collaborators (e.g., some
strategy subclass or interface implementation or a listener
implementation). The ORM doesn't make life easy when you want to
reconstitute an object of such a class. Sure, the attributes are easily
mapped from the row to the object, but not so with non-persistable items.
What do you do? Do you ditch the ORM?
--
---
You received this message because you are subscribed to the Google
Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
For more options, visit https://groups.google.com/d/optout.

--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Matteo Vaccari]

If you know which strategies you need at the moment you build the object,
you can simply have different methods:

fooRepository.findForSituationX(fooId);
fooRepository.findForSituationY(fooId);

or you can go all the way and do an abstract strategy (which is well
explained IMHO in this article:
http://www.pixelstech.net/article/1322574495-Why-I-love-everything-you-hate-about-Java
)

On Thu, Sep 24, 2015 at 12:32 PM, Christopher Gardner <

Post by Christopher Gardner
What if there are several strategies? How would the repository know which
one to set? I suppose you could add some attribute to indicate which to
use. That does throw a bit of blight on the class though.

Post by Matteo Vaccari
class FooRepository { // yes I know, not a good name
@Autowired EntityManager entityManager;
Foo find(FooId fooId) {
Foo foo = entityManager.find(fooId);
foo.setStrategy(new MyStrategy());
return foo;
}
}

Post by Matteo Vaccari
Not sure what it is that you find difficult. Could you move the code
that reconstitute an object to a repository object?

Post by ACP
Assume you have a legacy application that uses an ORM framework such as
Hibernate or another JPA application and a relational database that you
can't easily replace. You've read GOOS and want to follow the GOOS style
for new features and redesigning small parts of the existing code as time
allows. You're creating classes whose objects must be persisted. The
internal design of a typical new class contains a few attributes that must
be persisted and one or more non-persistable collaborators (e.g., some
strategy subclass or interface implementation or a listener
implementation). The ORM doesn't make life easy when you want to
reconstitute an object of such a class. Sure, the attributes are easily
mapped from the row to the object, but not so with non-persistable items.
What do you do? Do you ditch the ORM?
--
---
You received this message because you are subscribed to the Google
Groups "Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to
For more options, visit https://groups.google.com/d/optout.

--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.

[Nat Pryce]

This issue arises whenever you have to combine objects with different
lifecycles. The ORM manages the lifecycle of persisted objects but the
application wants the persisted objects to talk to objects that have a
different lifecycle that the ORM does not know about.

One solution is to pass the strategy object that you want the persistent
object to talk to as a parameter to the methods of the persisted objects.

E.g.

// Get a persisted object from the ORM
Order order = orderBook.orderWithId(httpRequest.getParameter("order");

// Create a strategy that the ORM cannot know about
SpecialOffer offer = offers.offerForVoucherCode(
httpRequest.getParameter("voucher"));

// Pass the strategy to the persisted object
order.totalCost(offer);
\--Nat

Post by ACP
Assume you have a legacy application that uses an ORM framework such as
Hibernate or another JPA application and a relational database that you
can't easily replace. You've read GOOS and want to follow the GOOS style
for new features and redesigning small parts of the existing code as time
allows. You're creating classes whose objects must be persisted. The
internal design of a typical new class contains a few attributes that must
be persisted and one or more non-persistable collaborators (e.g., some
strategy subclass or interface implementation or a listener
implementation). The ORM doesn't make life easy when you want to
reconstitute an object of such a class. Sure, the attributes are easily
mapped from the row to the object, but not so with non-persistable items.
What do you do? Do you ditch the ORM?
--
---
You received this message because you are subscribed to the Google Groups
"Growing Object-Oriented Software" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.