Pass domain objects to presentation layer, but not to modify them?

[leonchen]

One paragraph from chapter 1 of "Professional Java Development With The Spring Framework":


"The Big Picture

...Domain objects will typically be passed up to the presentation layer, which will display data they contain, but not modify them, which will occur only within the transactional boundaries defined by the business services layer. ... "

Q1: So, If I pass the domain objects to the presentation layer, and let the user modify the object's contents directly, then send back to service layer to update db, will there be any problem?

Q2: What could be the best practice to organize the CRUD functions? Read the Domain Objects in the service layer then transfer them to Transfer Objects to presentation layer?

Thanks for your any opinion!

[karldmoore]

There are have been lots of threads about this debate. I would have a look through the previous threads, they might answer your questions.

http://forum.springframework.org/showthread.php?t=30251
http://forum.springframework.org/showthread.php?t=19429

[Alarmnummer]

One paragraph from chapter 1 of "Professional Java Development With The Spring Framework":


"The Big Picture

...Domain objects will typically be passed up to the presentation layer, which will display data they contain, but not modify them, which will occur only within the transactional boundaries defined by the business services layer. ... "

Q1: So, If I pass the domain objects to the presentation layer, and let the user modify the object's contents directly, then send back to service layer to update db, will there be any problem?

I think they presentation layer should not be able to modify your domain objects. The fact that you are exposing your domain object in the presentation layer is questionable, but still a preferred choice because creating DTO's is a lot of work.

So it should be a design guideline: don't modify domain objects in the presentation layer.

And if you use AspectJ, you can even enforce it.

Q2: What could be the best practice to organize the CRUD functions? Read the Domain Objects in the service layer then transfer them to Transfer Objects to presentation layer?

It saves time exposing the domain objects in the presentation layer (instead of writing dto's). So I would choose that option, and apply the design guideline I gave above.

[madtree]

I think they presentation layer should not be able to modify your domain objects. The fact that you are exposing your domain object in the presentation layer is questionable, but still a preferred choice because creating DTO's is a lot of work.

So it should be a design guideline: don't modify domain objects in the presentation layer.

And if you use AspectJ, you can even enforce it.


It saves time exposing the domain objects in the presentation layer (instead of writing dto's). So I would choose that option, and apply the design guideline I gave above.

Or you implement some restrictive interface and expose them in the presentation layer.

[karldmoore]

Or you implement some restrictive interface and expose them in the presentation layer.

Although I agree, I do prefer Peter's AspectJ solution. I program to interfaces anyway thus restricting access, but if its strictly enforced it won't go wrong.

[leonchen]

... So it should be a design guideline: don't modify domain objects in the presentation layer.

And if you use AspectJ, you can even enforce it.


It saves time exposing the domain objects in the presentation layer (instead of writing dto's). So I would choose that option, and apply the design guideline I gave above.

Thanks!

Could you give me a hint, how to expose the domain objects in the presnetation layer for Upating but will not modify domain objects in the presntation layer (and without writing dto)?

Thanks!

[karldmoore]

Someone suggested having an interface which would be a good idea. Only expose getter methods to the presentation. Peter also said about using AspectJ, this article has an example of that.

http://debasishg.blogspot.com/2006/0...aky-model.html

[leonchen]

Someone suggested having an interface which would be a good idea. Only expose getter methods to the presentation. Peter also said about using AspectJ, this article has an example of that.

http://debasishg.blogspot.com/2006/0...aky-model.html

Thanks!

I think the interface and AOP are trying to enforce the presentation layer not to modify the domain objects.

But my problem is that, without modifying domain objects, how to send the modified data about the domain objects back to the service layer (and don't use DTO)?

For example, I have an domain class: Insurance, which has more then 30 properties and complex object relations. Users want to modify the Insurance domain objects' properties, what will be the best practice (and fast programming way) to send the modified properties back to service layer?

1. create a service method which has more then 30 parameters.
2. create DTO.
3. send the domain object to the presentation layer, let the presentation layer directly modify the domain object, and then send back to the service layer.
4. other?

Thanks for your any opinion.

[Jörg Heinicke]

But my problem is that, without modifying domain objects, how to send the modified data about the domain objects back to the service layer (and don't use DTO)?

I guess you have to do the one or the other. And I wonder what should be bad about modifying domain objects - as long as you don't write directly to the database. I do not use OSIV at all and I don't think it's a good idea to use it. The service layer has to care about persisting the changes or transactional boundaries in general as already mentioned.

Regards
Jörg

[Alarmnummer]

Thanks!

I think the interface and AOP are trying to enforce the presentation layer not to modify the domain objects.

But my problem is that, without modifying domain objects, how to send the modified data about the domain objects back to the service layer (and don't use DTO)?

Make an object that contains the changes: EmployeeMoveRequest eg.

For example, I have an domain class: Insurance, which has more then 30 properties and complex object relations. Users want to modify the Insurance domain objects' properties, what will be the best practice (and fast programming way) to send the modified properties back to service layer?

In most cases he only wants to change certain aspects, so try to make an object that contains these changes.

This is my preferred way.. but if there is not much logic (unlike in your case I guess) the fastest solution would be to expose the domain objects and just create a update method on your application services.

Check the following blog:
http://peter.jteam.nl/?p=11

1. create a service method which has more then 30 parameters.

We both know this is a big no-no.

2. create DTO.

DTO is not a good name here I guess. But creating some data container that contains the changes would be my preferred solution.

3. send the domain object to the presentation layer, let the presentation layer directly modify the domain object, and then send back to the service layer.

See the bloglink.

Thanks for your any opinion.

No problem.

Ps: don't take my answers for granted. I'm interested in the subject, but I also make mistakes and have to learn new stuff. So the answers I have given reflect my current understanding and opinion.