Hi all,
In my project I am using Struts Framework, Business Objects, Transfer object, DAO design pattern, View Helpers etc.
I want to understand the relationship between these classes
Form-Action-Service-BusinessObject-TransferObject-ViewHelper-DAO
Can anybody explain me the relationship between these classes
Thank you
> Hi all,
>
> In my project I am using Struts Framework, Business
> Objects, Transfer object, DAO design pattern, View
> Helpers etc.
How did you decide to use these without understanding anything about them?
Did somebody choose them for you? Can you ask them why they chose this way?
.> I want to understand the relationship between these
> classes
>
> Form-Action-Service-BusinessObject-TransferObject-View
> Helper-DAO
>
> Can anybody explain me the relationship between these
> classes
Yes.
Just one question: What did Google bring back when you typed each of these terms into the query text box?
Are you telling me you didn't even bother to do that?
Here's my take:
Form - I don't use Struts myself, thank God, but I believe this is a Java representation of an HTML form. It allows you to bind HTTP request values to a Java object, perform validation, etc.
Action - Struts lets you map different Action classes to different web pages and events to accomplish tasks. You embed your code to perform something when a JSP event occurs.
Service - More generic than an Action. Action uses the HttpRequest and HttpResponse classes, which ties it to the web tier. Services are more generic, in that their parameter lists don't include anything from the web tier.
BusinessObject - A Java object, usually a Java Bean or EJB, that encapsulates some concept pertinent to your business use cases (e.g., Order, OrderItem, Customer, Invoice, etc.)
TransferObject - A Java object whose sole purpose is to ferry data from one tier to another in a multi-layered application.
View Helper - I believe this is a Core J2EE pattern, but I don't know exactly what it is myself. I don't use it. Google for Core J2EE or View Helper.
DAO - Data Access Objects encapsulate all persistence code in an app. I believe this term is on its way out in favor of Repository, if Martin Fowler is to be believed.
%
