File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes JSP and the fly likes Isolating business layer from presentation Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » JSP
Bookmark "Isolating business layer from presentation" Watch "Isolating business layer from presentation" New topic
Author

Isolating business layer from presentation

Joe Gliniecki
Greenhorn

Joined: Oct 25, 2007
Posts: 18
Hi,
I'm volunteering for the local school district, which runs their internal applications on Tomcat. They use SQL2JAVA for O/R mapping, but run their database calls from the JSPs and have no type of controller of MVC framework at all.

I come from a Java SE background and am learning Java EE, but have read enough to learn that there needs to be a core business layer.

I'm trying to create a clean separation between presentation/domain/persistence layers. This was pretty easy for persistence, using a factory and interface for DAOs, and implementing the DAOs for SQL2JAVA. That way if we want to switch to another O/R mapper, it would be relatively painless.

For the boundary between presentation and business is where I have some questions. I created a very basic FrontController. Would the command objects of the FrontController be considered to be on the presentation side? I also created a class that has course grained methods for calling the domain (similar to what a lot of literature calls a facade). Would this class be considered part of the domain?

Also, my domain objects are similar to the tables in the database. For now, I am returning these objects to the JSPs. Is it standard practice to have separate Data Transfer Objects so that the domain doesn't creep into the presentation layer?

Sorry about this getting long. To summarize, I'm creating a domain layer (where none existed before) and would like to isolate it enough so that we can have flexibility for the future in choosing/changing MVC frameworks and O/R mappers without modifying the core application.

Thanks,
Joe
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61654
    
  67

Originally posted by Joe Gliniecki:
I created a very basic FrontController. Would the command objects of the FrontController be considered to be on the presentation side?


Yes. Think about it this way: ask yourself if something would need to be discarded should you wish to put a Swing or command-line interface on your business layer? Would the Commands have to go? Yes. Therefore, they are not part of the business layer, but part of the presentation.

I also created a class that has course grained methods for calling the domain (similar to what a lot of literature calls a facade). Would this class be considered part of the domain?

Apply the same question. Does the class go or stay if the presentation layer needs to be replaced?

Is it standard practice to have separate Data Transfer Objects so that the domain doesn't creep into the presentation layer?

Generally, yes. You certainly don't want resultsets and the like propagating upwards (though you seem to have abstraction at that level on the right path). It's common to employ DTOs to send data to the presentation layer. If these DTOs follow the JavaBean pattern, they are immediately usable by the EL on the JSPs.
[ February 05, 2008: Message edited by: Bear Bibeault ]

[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Joe Gliniecki
Greenhorn

Joined: Oct 25, 2007
Posts: 18
Thanks Bear - that helps a lot.

A few follow up questions, though.

Does the DTO typically hold data formatted for the JSP? For example, if the domain object uses a boolean for a value, but we would like to present Yes/No to the user. Should the DTO hold a string, and the assembler that converts from domain to DTO change the boolean to a string? Or would there be code in the DTO itself to do this? Or just do it on the JSP with a custom tag?

Also, it seems to me that the domain object would be the place to have validation code (ie: required fields have values before creating an object). Is there a commonplace and accepted way to return error messages, etc. back to the presentation layer that would be generic enough regardless if using Struts/Swing/CommandLine/whatever for presentation?

Lastly, are there naming conventions for the things we've been discussing? If I'm dealing with a Title class in my domain, would it be TitleDAO, TitleDTO, TitleFacade?

Thanks,
Joe
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Originally posted by Joe Gliniecki:

Does the DTO typically hold data formatted for the JSP? For example, if the domain object uses a boolean for a value, but we would like to present Yes/No to the user. Should the DTO hold a string, and the assembler that converts from domain to DTO change the boolean to a string? Or would there be code in the DTO itself to do this? Or just do it on the JSP with a custom tag?


That could be done either way.
I used to lean more toward having multiple accessors for things like that.
With El it's pretty easy to dress these things up in the JSP so I've been doing more in the view tier



Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61654
    
  67

Originally posted by Joe Gliniecki:
Does the DTO typically hold data formatted for the JSP?

Even though I keep in mind that a DTO may end up being sent to a JSP, I do not change or store the data in way that only makes sense for the display.

Your example of a boolean is a good point. I would not store the data as "Yes/No" string -- it would be stored as a boolean. Display format considerations should take place on the display.

For this example, no custom tags necessary; the EL can handle this quite easily:


Also, it seems to me that the domain object would be the place to have validation code (ie: required fields have values before creating an object).


Validation should occur at many levels. The domain object should perform validation for domain considerations. The display will perform display-oriented validation. It's not uncommon for my data to be validated 4 times: once on the client (for user convenience only), once in the controller, once in the business layer, and once at the persistence layer. None of these layers can make any assumptions about what goes on in the other layers if they are to remain independent.

Is there a commonplace and accepted way to return error messages

The closer to the user the validation error is detected, the better message can be delivered. I do a lot of client-side validation so that the user gets a quick and pertinent message before sending the bad data. If the failure is only detectable on the server, a response back to offending page is made with an error list. It's the responsibility of each layer to make sure that it's defined in a way that its next upper layer can get and process the errors.

In other words, the business layer knows nothing of form fields or scoped variables and the like. Upon failure, it delivers a list of errors to the controller in a UI-agnostic fashion. The controller is responsible for packaging this up in a manner suitable for its presentation.

Lastly, are there naming conventions for the things we've been discussing? If I'm dealing with a Title class in my domain, would it be TitleDAO, TitleDTO, TitleFacade?

Every operation seems to have its own style. Pick one that makes sense and is consistent. Personally, I tend to use simple names like Title. (Aside: for me, this is usually an interface implemented by the DTO that contains only the accessors that I intend to use at the presentation layer).
[ February 05, 2008: Message edited by: Bear Bibeault ]
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 61654
    
  67

KLUNK!

And yes, Ben and I are twin brothers of separate mothers.
Joe Gliniecki
Greenhorn

Joined: Oct 25, 2007
Posts: 18
Thanks guys, that really helps.

Bear, what are your primary reasons for using DTOs? I've been doing some more digging, and have found folks on both sides of the fence on this issue on JavaRanch and TSS.

I will have to use some DTOs because of some statistics that when requested, are generated on the fly and don't really exist in the domain model. For me it comes down to maintaining a separation of concerns between presentation and business layers vs. the overhead of creating and maintaining DTO assemblers and the DTOs themselves. Are there other tradeoffs?

Thanks,
Joe
 
With a little knowledge, a cast iron skillet is non-stick and lasts a lifetime.
 
subject: Isolating business layer from presentation