Prev: One Of The Easiest Ways To Promote Your Site!
Next: NegativeArraySizeException ... IndexOutOfBoundsException ...
From: Tom Anderson on 4 Jan 2010 05:06
On Sun, 3 Jan 2010, Arved Sandstrom wrote:

> Tom Anderson wrote:
>> On Sat, 2 Jan 2010, Arved Sandstrom wrote:
>>
>>> Tom Anderson wrote:
>>>> On Wed, 30 Dec 2009, Lew wrote:
>>>>
>>>>> Entity objects are not really meant for a lot of manipulation outside
>>>>> the JPA context or by application logic.
>>>>
>>>> No, no, no. JPA is a mechanism, not a policy - JPA entities are not
>>>> 'meant' for anything. You might think it's a good idea to use JPA
>>>> entities that way, but it's something i'd disagree very strongly with you
>>>> over - what you're advocating is an Anemic Domain Model, and it's a bad
>>>> thing (Martin Fowler says so, so it must be true! :) ):
>>>>
>>>> http://martinfowler.com/bliki/AnemicDomainModel.html
>>>
>>> I'm in general agreement with what's said in that link. However, in the
>>> context of JPA, I myself don't think of the entity classes by themselves
>>> as defining the domain layer in its entirety. I don't think of JPA entity
>>> classes as being domain classes at all, not by definition. Some happen to
>>> correspond to domain classes, some don't. To me JPA entity classes are
>>> fine-grained Java mappings to RDBMS tables, and that's about it. They are
>>> at the same level as iBatis mapping files.
>>>
>>> I tend to think of DAOs, which map to the real domain classes, as being
>>> the domain layer. Some JPA entities happen to have a 1:1 mapping to a
>>> domain class - many do not, and really aren't more than value objects or
>>> DTOs.
>>
>> Interesting. Are you essentially using JPA entities as behind-the scenes
>> data holders, wrapped by real domain objects? Or are you saying your domain
>> objects are more like a service layer? Could i trouble you for a very small
>> example of this, just in outline?
>
> Assuming your email is good, I can sanitize some work stuff and send some
> examples that way.

It is good, and that would be most kind - but only if it's not too much
trouble. I can then try to synthesise a noddy example to demonstrate your
approach, which i'll post to the group (and you can tell me if i've got it
right!).

> We just recently went through this exercise on a client site, where
> several apps had JPA but no data access layer (i.e. persistence code was
> scattered everywhere, including in the web tier), and in the course of
> building a DAL we realized that the DAOs most useful to the service
> layer (or to other DAOs in the domain layer) really did not, in most
> cases, map 1:1 to JPA entities.

But the key thing here is that you have a strong service layer - the DAOs
are almost a detail, i suspect. The service layer is where the business
logic lives, and JPA just supplies structs full of data to it.

> Yes, in a nutshell, in this picture JPA entities are both behind-the-scenes
> and low-level. Basically data holders as you say.
>
> As one very simple example, if you have two JPA entities related by a
> OneToMany/ManyToOne, and that's logically a strong composition
> relationship, it's probably more useful to have a single DAO that
> handles both entities. Logically the real domain object is the parent +
> those entities that can only co-exist with the parent. JPA does provide
> some facilities like @Embedded and @Embeddable to handle some of this
> for 1:1 situations), but I personally prefer to dispense with
> annotations like these, and to have explicit domain logic manage
> composition or aggregation relationships.

Fair enough. I was thinking that in JPA2 you can do aggregation with a
CollectionOfElements that holds Embeddables, so the contained objects
don't need to be entities. But this is, to some extent, jumping through
hoops in order to maintain a somewhat arbitrary kind of purity.

> As an aside, I'm not entirely happy with that Fowler link (nor with Eric
> Evans :-)). If I read it correctly they are suggesting that business
> rules live only in the domain layer (this is using their definitions of
> domain and service layers). I don't buy that - I think there are 2 types
> of business rules, and one set lives in the service layer.

Qualitatively different types? This is an intuitively attractive idea -
domain objects model the entities in the domain, with their natural,
intrinsic behaviour (eg valuing and repaying a mortgage), and the service
layer captures more transaction-script type behaviour (selling someone a
mortgage), if that's what you mean. This is an idea that goes all the way
back to the dawn of EJB, if not before. Is it right? Dunno. I'd be
interested to see how some big server-side Smalltalk systems did it :).

tom

--
Exceptions say, there was a problem. Someone must deal with it. If you
won't deal with it, I'll find someone who will.
From: Arved Sandstrom on 4 Jan 2010 07:37
Tom Anderson wrote:
> On Sun, 3 Jan 2010, Arved Sandstrom wrote:
>
>> Tom Anderson wrote:
>>> On Sat, 2 Jan 2010, Arved Sandstrom wrote:
>>>
>>>> Tom Anderson wrote:
>>>>> On Wed, 30 Dec 2009, Lew wrote:
>>>>>
>>>>>> Entity objects are not really meant for a lot of manipulation
>>>>>> outside the JPA context or by application logic.
>>>>>
>>>>> No, no, no. JPA is a mechanism, not a policy - JPA entities are not
>>>>> 'meant' for anything. You might think it's a good idea to use JPA
>>>>> entities that way, but it's something i'd disagree very strongly
>>>>> with you over - what you're advocating is an Anemic Domain Model,
>>>>> and it's a bad thing (Martin Fowler says so, so it must be true! :) ):
>>>>>
>>>>> http://martinfowler.com/bliki/AnemicDomainModel.html
>>>>
>>>> I'm in general agreement with what's said in that link. However, in
>>>> the context of JPA, I myself don't think of the entity classes by
>>>> themselves as defining the domain layer in its entirety. I don't
>>>> think of JPA entity classes as being domain classes at all, not by
>>>> definition. Some happen to correspond to domain classes, some don't.
>>>> To me JPA entity classes are fine-grained Java mappings to RDBMS
>>>> tables, and that's about it. They are at the same level as iBatis
>>>> mapping files.
>>>>
>>>> I tend to think of DAOs, which map to the real domain classes, as
>>>> being the domain layer. Some JPA entities happen to have a 1:1
>>>> mapping to a domain class - many do not, and really aren't more than
>>>> value objects or DTOs.
>>>
>>> Interesting. Are you essentially using JPA entities as behind-the
>>> scenes data holders, wrapped by real domain objects? Or are you
>>> saying your domain objects are more like a service layer? Could i
>>> trouble you for a very small example of this, just in outline?
>>
>> Assuming your email is good, I can sanitize some work stuff and send
>> some examples that way.
>
> It is good, and that would be most kind - but only if it's not too much
> trouble. I can then try to synthesise a noddy example to demonstrate
> your approach, which i'll post to the group (and you can tell me if i've
> got it right!).

Sounds like a plan. It shouldn't exactly be a major chore, seeing as how
we just went through the design exercise.

>> We just recently went through this exercise on a client site, where
>> several apps had JPA but no data access layer (i.e. persistence code
>> was scattered everywhere, including in the web tier), and in the
>> course of building a DAL we realized that the DAOs most useful to the
>> service layer (or to other DAOs in the domain layer) really did not,
>> in most cases, map 1:1 to JPA entities.
>
> But the key thing here is that you have a strong service layer - the
> DAOs are almost a detail, i suspect. The service layer is where the
> business logic lives, and JPA just supplies structs full of data to it.

It's perhaps more accurate to say for these particular client apps that
we had a _bulky_ service layer. :-) In fact these apps as written had
serious layering problems: no DAL, and business logic split about evenly
between session beans and JSF managed beans. Direct JPA calls were
present both in the session beans and also in the JSF managed beans.

If I may digress slightly, a J2EE (.NET for that matter) application
layering picture that I like (with comments related to a JSF app) is:

1) presentation layer (UI) - XHTML/formatting artifacts/backing bean
structures in JSF managed beans, with the beans acting in their role as
value holders for the pages;

2) application layer (UI) - JSF managed bean use-case UI workflow, with
the beans acting in their role as page controllers;

3) service layer - typically session beans as EJBs or web services,
MDBs. Transaction control, business logic spanning several domain objects;

4) domain layer - most of the business logic, that pertaining
specifically to domain object behaviour. DAOs, business objects,
whatever you want to call 'em;

5) persistence layer - JPA, iBatis, straight JDBC, files etc.

This should illustrate why I think of JPA the way I do.

So our problem was many-fold: moving service layer logic (in many cases
domain layer logic) from the application layer down to where it ought to
be, creating the domain layer, and fixing the persistence layer.

Strictly speaking when I refer to a data access layer (DAL), the meaning
I assign to that (YMMV) is that of the level of the persistence layer
that abstracts away the specific persistence technology. IOW, the domain
layer (the model) can ask the persistence layer to do things without
worrying about whether it's JPA or raw JDBC or stored procs, and it's
the DAL that decides whether to use JPA entities or to use JDBC.

Also, layers 1 & 2 together may be thought of as the client layer (the
UI layer). It should be possible for layers 3, 4 & 5, together, to
support either a JSF front end or WS clients or JMS, for example. In the
case of our application refactoring, this was one of the rules of thumb
- if we were to remove the current UI layer entirely, would logic get
removed that had to be in the service tier to support other types of
clients?

>> Yes, in a nutshell, in this picture JPA entities are both
>> behind-the-scenes and low-level. Basically data holders as you say.
>>
>> As one very simple example, if you have two JPA entities related by a
>> OneToMany/ManyToOne, and that's logically a strong composition
>> relationship, it's probably more useful to have a single DAO that
>> handles both entities. Logically the real domain object is the parent
>> + those entities that can only co-exist with the parent. JPA does
>> provide some facilities like @Embedded and @Embeddable to handle some
>> of this for 1:1 situations), but I personally prefer to dispense with
>> annotations like these, and to have explicit domain logic manage
>> composition or aggregation relationships.
>
> Fair enough. I was thinking that in JPA2 you can do aggregation with a
> CollectionOfElements that holds Embeddables, so the contained objects
> don't need to be entities. But this is, to some extent, jumping through
> hoops in order to maintain a somewhat arbitrary kind of purity.

I myself am not religious about any implementation approach. I only
expect (again, YMMV) that the domain layer take precedence over
persistence layer plumbing. Provided that the DAOs/business objects are
nicely designed, and that the top-level of the persistence layer that
they see (the DAL) makes no reference to JPA, I don't care what
annotations are used in the supporting JPA entities.

It is my gut feeling, however, that a number of JPA annotations are best
suited to folks who have a more collapsed layering approach, in other
words those who have dispensed with some of the above distinct layers.
For example, a concrete decision to always go with JPA and hence get rid
of the DAL. I'm not saying this is wrong - different situations call for
different architectures. I've merely offered one architecture up that
seems to work well for larger J2EE apps.

>> As an aside, I'm not entirely happy with that Fowler link (nor with
>> Eric Evans :-)). If I read it correctly they are suggesting that
>> business rules live only in the domain layer (this is using their
>> definitions of domain and service layers). I don't buy that - I think
>> there are 2 types of business rules, and one set lives in the service
>> layer.
>
> Qualitatively different types? This is an intuitively attractive idea -
> domain objects model the entities in the domain, with their natural,
> intrinsic behaviour (eg valuing and repaying a mortgage), and the
> service layer captures more transaction-script type behaviour (selling
> someone a mortgage), if that's what you mean. This is an idea that goes
> all the way back to the dawn of EJB, if not before. Is it right? Dunno.
> I'd be interested to see how some big server-side Smalltalk systems did
> it :).
>
> tom

Your examples have captured my thoughts precisely. The service layer is
a bunch of facades, each tying together domain object interactions. It's
entirely plausible to me that this tying together of business object
interactions also is a form of business rules.

AHS
From: Lew on 4 Jan 2010 09:35
Lew wrote:
>>>>>> Entity objects are not really meant for a lot of manipulation
>>>>>> outside the JPA context or by application logic.

Tom Anderson wrote:
>>>>> No, no, no. JPA is a mechanism, not a policy - JPA entities are not
>>>>> 'meant' for anything. You might think it's a good idea to use JPA
>>>>> entities that way, but it's something i'd disagree very strongly
>>>>> with you over - what you're advocating is an Anemic Domain Model,
>>>>> and it's a bad thing (Martin Fowler says so, so it must be true! :) ):
>>>>>
>>>>> http://martinfowler.com/bliki/AnemicDomainModel.html
....

Tom Anderson wrote:
> But the key thing here is that you have a strong service layer - the
> DAOs are almost a detail, i suspect. The service layer is where the
> business logic lives, and JPA just supplies structs full of data to it.
> ...
> Qualitatively different types? This is an intuitively attractive idea -
> domain objects model the entities in the domain, with their natural,
> intrinsic behaviour (eg valuing and repaying a mortgage), and the
> service layer captures more transaction-script type behaviour (selling
> someone a mortgage), if that's what you mean. This is an idea that goes
> all the way back to the dawn of EJB, if not before. Is it right? Dunno.
> I'd be interested to see how some big server-side Smalltalk systems did
> it :).

IOW, "Entity objects are not really meant for a lot of manipulation outside
the JPA context."

--
Lew
From: Arved Sandstrom on 4 Jan 2010 13:18
Lew wrote:
> Lew wrote:
>>>>>>> Entity objects are not really meant for a lot of manipulation
>>>>>>> outside the JPA context or by application logic.
>
> Tom Anderson wrote:
>>>>>> No, no, no. JPA is a mechanism, not a policy - JPA entities are
>>>>>> not 'meant' for anything. You might think it's a good idea to use
>>>>>> JPA entities that way, but it's something i'd disagree very
>>>>>> strongly with you over - what you're advocating is an Anemic
>>>>>> Domain Model, and it's a bad thing (Martin Fowler says so, so it
>>>>>> must be true! :) ):
>>>>>>
>>>>>> http://martinfowler.com/bliki/AnemicDomainModel.html
> ...
>
> Tom Anderson wrote:
>> But the key thing here is that you have a strong service layer - the
>> DAOs are almost a detail, i suspect. The service layer is where the
>> business logic lives, and JPA just supplies structs full of data to it.
>> ...
>> Qualitatively different types? This is an intuitively attractive idea
>> - domain objects model the entities in the domain, with their natural,
>> intrinsic behaviour (eg valuing and repaying a mortgage), and the
>> service layer captures more transaction-script type behaviour (selling
>> someone a mortgage), if that's what you mean. This is an idea that
>> goes all the way back to the dawn of EJB, if not before. Is it right?
>> Dunno. I'd be interested to see how some big server-side Smalltalk
>> systems did it :).
>
> IOW, "Entity objects are not really meant for a lot of manipulation
> outside the JPA context."
>
That's the point we returned to, yes. :-)

I might add, upon further review, that I did not invent the layers I
described earlier. Those are from pp 128-129 of "EJB Design Patterns" by
Marinescu, which is freely available from TSS after registration. I
happen to like the chosen layers and his description of same.

AHS
From: Tom Anderson on 6 Jan 2010 05:45
On Mon, 4 Jan 2010, Lew wrote:

> Lew wrote:
>>>>>>> Entity objects are not really meant for a lot of manipulation outside
>>>>>>> the JPA context or by application logic.
>
> Tom Anderson wrote:
>>>>>> No, no, no. JPA is a mechanism, not a policy - JPA entities are not
>>>>>> 'meant' for anything. You might think it's a good idea to use JPA
>>>>>> entities that way, but it's something i'd disagree very strongly with
>>>>>> you over - what you're advocating is an Anemic Domain Model, and it's a
>>>>>> bad thing (Martin Fowler says so, so it must be true! :) ):
>>>>>>
>>>>>> http://martinfowler.com/bliki/AnemicDomainModel.html
> ...
>
> Tom Anderson wrote:
>> But the key thing here is that you have a strong service layer - the DAOs
>> are almost a detail, i suspect. The service layer is where the business
>> logic lives, and JPA just supplies structs full of data to it.
>> ...
>> Qualitatively different types? This is an intuitively attractive idea -
>> domain objects model the entities in the domain, with their natural,
>> intrinsic behaviour (eg valuing and repaying a mortgage), and the service
>> layer captures more transaction-script type behaviour (selling someone a
>> mortgage), if that's what you mean. This is an idea that goes all the way
>> back to the dawn of EJB, if not before. Is it right? Dunno. I'd be
>> interested to see how some big server-side Smalltalk systems did it :).
>
> IOW, "Entity objects are not really meant for a lot of manipulation outside
> the JPA context."

Uh, that's not a paraphrase of what i wrote.

tom

--
Mpreg is short for Male Impregnation and I cannot get enough. -- D
First  |  Prev  | 
Pages: 1 2 3 4 5
Prev: One Of The Easiest Ways To Promote Your Site!
Next: NegativeArraySizeException ... IndexOutOfBoundsException ...