I have been handed a large Spring - Hibernate project and have been told to go through the code and figure out how it works.
I have been able to run the project in JBoss and access pages locally, but I have no idea how to figure out how the program is layed out, as I have no web programming experience.
I have been told that it is "pretty simple" and is a "normal Spring-Hibernate project."
Any idea where to begin?
Well, for starters, you'll really need to learn at least the basics of how these frameworks operate. Here's a tutorial on Spring MVC, and here's a Hibernate tutorial.
You'll need to identify the classes that create the various layers; there are certainly going to be Controller classes (which take a web request and figure out how to construct the response) and DAO classes (Data Access Objects, which manage saving and retrieving data).
There will probably be JSP files which describe the views; that is, what the user sees. The HTML code that builds the actual web pages should be here.
My suggestion: pick one simple page and follow it through. Where's the JSP that sets up the HTML for that page? Where's the controller it gets POSTed to? Does that controller call a service class or a DAO? A validator? Etc. -- type in one bit of data and follow it all the way through. It will help to have an IDE that shows you the structure of the application, and allows you to go into debug mode and step through the code.
Good luck!
Related
I'm developing a Web app (unfortunately a legacy one) in java (that runs on tomcat) with a very small, but not well organized (at least on this particular project), group and let me start by saying we have not much of experience in servlets programming.
The issue is the folloing.
I'm having kind of a trouble as the amount of servlets keep growing and growing while we implement new functions in this webapp. We don't have a project to follow and structure. Just the clint who randomly asks for new functionality out of the blue.
I would just say our web.xml is a mess. I think we should avoid to pollute the web.xml so much with new servlet every time (right now is about 800 lines and it's becoming hard to maintain), but i'm not sure about what i should do about it.
I'm exploring different possibilities, but we can't afford to explore too much so i would like to hear some idea or best practies from people with more experience than us.
I was thinking that maybe we should use CORBA ore something like that to implenet some kind of RPC. So while grouping common functionalities in a few bunch of servlets we could tame the chaos. Could it be a good idea?
What i have in mind is something like a few servlets that pose as entry points for the requests. I would like to group them by the type of response they give. So for example i have a servlet that serves me json after calling some other class that actually do the job to extract data ore manipulating data. Or again i would have a servlet that serves me files, files that another class or servlet produce. And so on. Am i looking at the problem in the right way?
I took a looked at some framework like DWR (Direct Web Remoting) but we would need to integrate it with a legacy webapp with ugly jsp pages full of scriptlet and we can't afford to jump into full ajax web pages in the limited time we have for the project.
We would need something more lightweight.
The more i search for a solution the more i get confused and overwelmed by the possibilities i find (REST, ORB, RPC, JSON-RPC...), so i ask for your help. Thanks in advance for every answers and tips.
You should definitely look into the Spring framework which is the de-facto standard for Java web development nowadays: http://projects.spring.io/spring-framework/
The Play Framework is also an interesting framework, giving you a Ruby-like development cycle: https://www.playframework.com/
Hello many of your points are valid so you can use new frameworks like spring or struts but it needs huge change over as many new levels will get added/introduced.But if you want to just get ride of many servlets you can/should use MVC architecture like framework in addition to that use a central level controller(a main servlet)-this will just take the request and checks in it (like switch case) as soon as switch case matched that helper class / utility class should called via instance or statically after that the response should also from that helper/utility class and should be sent to the main controller and that main controller will send it to respective jsps/html.
Im new to Wicket and Hibernate. I have watched the youtube videos and read som chapters about Hibernate. I still have a question that I need to know before Im able to use Hibernate:
In wicket we have Application.java (for all the common things) and a java file for eache "page" in the application, for instance login.java, register.java etc. What should go in Application.java and what is good programming practise when using Hibernate in Wicket?
All the examples I have seen is ither with other frameworks like Wicket togheter with Spring or examples using just one file, the Application.java fil. Gess Im comfused and really miss an example using at least Application.java, one class file and one .java file for som function like saving forms, retriving db etc..
I dont know if its important, but Im using Netbeans in this project.
Any tips welcome
In my opinion the best way is to keep the persistence layer away from the presentation layer (in order to achieve a clean MVC architecture).
In this case this means you should put your Wicket related initialization logic in your Application class (more specifically WebApplication, since you are discouraged from subclassing Application directly) and put the persistence related logic in your DAO-s (preferably well encapsulated in a service layer).
You can find more information about the DAO pattern in the DAO Pattern and about transaction based persistence with Wicket, Spring and Hibernate here
You should create DAO - class with main functions (geting, saving, updating objects) and create instance in WebApplication class. For example you have:
public class WebApp extends WebApplication {
private final MyDAO myDAO = new MyDAO();
public MyDAO getMyDAO() {
return myDAO;
}
init(){
...
}
...
}
and in page classes you can get this instance using
((WebApp)Application.get()).getMyDAO()
P.S.
And please, don't use additional component.. only hibernate + wicket. I Agree with Paarth, if you don't know wicket and hibernate you should start from tiny test project for wicket and for hibernate
In this case, when you are new to both Hibernaet & Wicket, try learning one after another.
Make some demo/POC project for Hibernate with Simple Java program.
Then go on Wicket, make some demo on that also.
Then make some small web application, integrating Hibernate and Wicket together as you have learned.
You should be going easy, thoroughly.
Hibernate should be pretty easy if your OOP concepts are clear. I don't have idea about Wicket, so can't say on it.
For implementing Wicket with Hibernate, take a look at Databinder (http://github.com/n8han/Databinder-for-Wicket/). It is an excellent, thin layer between Wicket and Hibernate (among other data handlers).
However, Databinder's core was written for something like Wicket 1.2 and hasn't been updated in quite some time. Several people say they're going to update it (including myself) and they haven't.
So, Databinder is a great model of how to use Wicket and Hibernate. However, in practice, it has several flaws that need to be addressed.
For a quick fix, check out Databinder version 1.3.2.CAST at http://comp.cast.org/maven2/ which at least brings Databinder in line with the latest Hibernate.
For a complex and incomplete, but powerful, implementation of this code, see http://code.google.com/p/cast-wicket-modules/
For a completed project that uses those modules, see https://code.google.com/p/udl-curriculum-toolkit/
All of those links are works in progress, but a place to start.
When asking this I answered myself: use a jsp.
But ok, what about a lightweight, easy to use framework?
It would be perfect if this framework had Eclipse plugin,
so that I could generate all code in one click and simply fill one method body (populate it with the data), then in one click
create a war file using a wizard
and deploy it on Tomcat.
Are there such frameworks?
p.s. I use spring, but I think there are ways to integrate it into every framework.
Take a look at Spring Roo.
If you only want to list a few DB records, I would just implement it dirty with a simple JSP with scriptlets. But you could also use the JSP SQL Tag library for that.
A simple one method body controller that needs that forwards to a view can most easily be writen with the Stripes framework that forwards to a JSP view (see wikipedia code example for how easy this can be done).
Generating nice tables in JSP can quickly be done by the popular Display Tag library.
If your not afraid to learn something new take a look at Grails
One of the big advantages of Grails is that its a full stack environment. Meaning that out of the box you get everything you need for your web app development
Test Servlet container (Tomcat)
Test database (hypersonic)
ORM (hibernate)
etc.....
Once installed just run
> grails create-app
Then you have a complete runnable application. (Auto bootstraps your project creation and config)
I need to implement quite big system in Seam. I'm considering the way of designing the architecture. If it's good to use page controllers or application controllers or front controller or every each of them. If it's helpful to use backend bean or maybe there's no need to do that. If you have any suggestion or link to helpful article I will appreciate it.
Thanks a lot!
Daniel Mikucki
If you need to learn a lot about Seam for a project, I recommend you get the Seam In Action book, which is the best on the subject.
To answer your question, personally I prefer to use the pull-MVC style in Seam, where you refer to data in your view templates that Seam takes care of initialising, as needed, using #Factory methods. However, there is more than one way to do it in Seam, so it is worth reading about the alternatives first, hence the book recommendation.
Alternatively, build a few Seam applications first to throw away before you try to build one 'right' :)
Daniel,
It is good practice to use a front controller, most people aren't aware of that design pattern.
It is a really good design pattern to use because it ensures you are accessing the application through a single entry point. You can monitor everything that comes and goes easily with less configuration. You reduce the amount of possible code duplication because there is a single entry point. In addition to having less code to maintain, the code should be easier to follow since there is only one way in. You can then easily follow the execution flow of the application.
Unfortunately for Seam, there isn't really a front controller pattern. I haven't spent as much time as I would like to develop my own, but security and audit-ability are my number one focus.
As far as page / application controllers go, in Seam, you have more contexts or scopes available. Event, Page, Conversation, Session, Application, to name most of them.
If you're developing a controller or in Seam, a page action, most of the time, it will be event based. That is the shortest lived scope. If you have page flows, you would then use conversational-scoped components.
Take a look at the examples in the source code. You can do a lot with very little code, it is amazing, but at the same time, there is a lot going on that may take a while to pick up on.
The n-tier design that most places follow doesn't necessarily apply here. For most of my pages, I define a query that I'll use in XML (entity query), then I'll inject it into my page action and call it there. So instead of having a controller, service, dao, and entity classes, you end up with simply a page action, the queries, and entity classes. You can cut out the service and dao layers in most cases.
Your whole definition of a service might change too. For me, a service is a service provider such as notification, security (auditing), exception handling, etc. all of these services run in the background and are not tied to a particular http request.
Walter
Daniel,
I have used one controller per page, one service and one dao per entity.
Use case logic goes in the controller
Entity specific business logic goes in entity service.
Actions which span multiple entities you can create a facade service - something which sits between controller and entity services
While the above is a good and practical approach, ideally:
you could break out any non MVC code from controller into its own service class, ie. 1 service class per page
you should only access the entity dao via the entity service.
Here's how the control would flow:
Ideally:
UI
-> PageController.java
-> PageService.java
-> EntityService.java
-> EntityDao.java
Practically, you could trim down a few layers:
UI -> PageController.java -> EntityService.java
Or for actions touching multiple entities:
UI -> PageController.java -> Facade.java -> Entity1Service.java,Entity2Service.java
PageController.java would be a Seam #Component and in your ui you can refer it as:
#{pageController} and pull the data from the view.
In architecture, the most important thing is how you layer things in the stack is avoid circular dependencies between layers. For example, Entity Service should not reference Controller and so on.
The other important thing is to be consistent about layering in the entire application. Use code generators if you can to keep your code consistent across the application, it really pays off for large projects. Look into Clickframes if you are interested in code generation (Clickframes generates starter code for Seam apps with full JPA/valdiation/security support which you can then modify). See this Seam demo build with Clickframes if interested.
I am in the middle of creating my own custom MVC web framework for a project. This project has very old code base where one JSP page directly submits a form to another JSP whereas the paths are also hardcoded. Now it is a big project and putting Struts or JSF will take considerable amount of time.
So my suggestion is to build a small custom MVC framework and convert many existing page flows into it and also encourage them to develop newer applications using this new MVC frameworks.
I would like to review this with all of you whether it makes sense or we should directly go to the standard MVC frameworks.
My idea
1. Create one front controller servlet which will have URL pattern like /*.sm
2. This servlet reads one config file and creates a map whose key is requestedURI and value is the class name of the command bean.
3. upon intercepting any action request it reads the parameter map (request.getParameterMap()). This servlet refers the already built map, understand whose command bean is to be invoked? Creates an instance of this command bean.
4. pass the parameter map to this command bean and calls execute method.
5. if any exception is found, front controller servlet forwards the request to one global error page
6. if everything is fine, it then forwards the request to the expected URI (by removong .sm and replace it with .jsp)
Do you think I am missing anything here? I know I can make it more fancy by providing error page per request page in the config file or so but those can be done later as well.
I think that you will end up reinventing the wheel rolling your own MVC framework. I know that it is tempting to make your own, since you won't have to get used to a new API but instead create your own and you can more easily adapt it to your specific usecases. But since it seems to be a very long lived application you will have to consider the fact, that your own framework (which may now be state of the art) will be legacy in a couple of years, too.
And that's where adapting one of the popular frameworks comes in handy. The creators of a new framework usually want others to move, too, so they will (or should) offer easy integration or migration options away from the frameworks they think they are doing better (Spring is a good example since it e.g. seamlessly integrates with existing Struts applications and you can gradually move your application without putting the old one into trash). Additionally most current frameworks are very versatile (which can sometimes be a problem since they need more time to get into it) and can be adapted to almost all usecases.
So I would recommend to review the existing solutions carefully (you can learn a lot from their design decisions and errors, too) and only start making your own if none of them matches your requirements.