CODEWITHSUNDEEP
javahibernatespringormspring-mvc
Mark Estrada
Mark Estrada

Reputation: 9191

Annotated Class in Hibernate

I am still trying my way around the Hibernate for some time now and I do think that I could make use of this framework rather than the hardcore JDBC approach.

It seems that every tutorial that I have looked at the net nowadays is making use of the annotated style POJO configuration. As such, I dont have problem with this and it makes coding a lot easier.

But I am having this thought.

Are the POJO that I am annotating, the same POJO that I will used when I need to get data from a user? What I mean is that, when user fills out a web form and I am using Spring MVC. I normally get a command object that maps to the user entried form. This is the same command object that I am persisting and these are just POJO's also.

In the Business Layer/Presentation Layer, I think there is a need for a Model Layer. For example, I have a Student Enrollment System. During the ADD Student Use case and in the Add Student form, I normally input the StudentID, First_Name, Last_Name.

In my servlet or in my controller, I usually map the Form Values into a concrete class. Spring does a good job in packaging the form values into a concrete class.

Sorry if my question might be a little vague but I just wanted to clear my thoughts. Kindly advise if my question still needs some detail.

Upvotes: 1

Views: 342

Answers (2)

Qwerky
Qwerky

Reputation: 18425

It seems like you are asking whether you can use the same class to represent an object through all layers of your application, from database (model) to business logic (controller) to presentation (view).

The answer is yes, but be careful. There may be certain aspects of your object that you want to protect, for example do you really want the view to be able to set the ID? While you might think its not a problem, you might change your mind when someone else does maintenance work on the use account page in 6 months time and decides to allow users to change their ID, just because the bean has a setID() method.

Upvotes: 1

Adeel Ansari
Adeel Ansari

Reputation: 39887

  1. It can be the same. Arguably, this is the point of having JPA and deprecate Entity Beans.

Other things doesn't have a question tone and looks fine to me, so can't really recognise if you have any other hidden question.

Upvotes: 1

Related Questions