Java Hibernate and servlets with Adobe Flex + Model View Controller Pattern ?

Question

Hi Guys,

I am preparing a document for a project. The project's backend is developed in Java, frontend is adobe flex. I am not sure about the correct way of describe the project in Model-View-Controller way.

For Model layer: Using Hibernate Java beans to implement all the business logic and persistence? For View Layer: Using Adobe flex send post or get request to Controller layer, and get respond in XML format. For Controller Layer: Using Java servlet to handle requests from Flex client?

Thanks

Answer 1

Hibernate - Model

Flex - View

Servlets - Controller

Brief lift of complete nice article follows:

1. Model, is the data. Manipulates the internal state and fire events when the internal state changed.
2. View, the visual representation for the Model’s data (controls on the screen)
3. Controller, is responsible for interpreting the user actions on the view and make changes to the model. (usually an event handler in flex)

In reality there is no 100% demarcation between these three layers. Is not that easy to make them completely decoupled and usually we end up making some tradeoffs.

The controller will always know about the view and the view about the controller. Controller also knows about the model. In the end I could say that the model is the only piece of the MVC that can be “100% decoupled”.

Answer 2

You should check out the Adobe sponsored Cairngorm Framework for your Flex application. It's arguably the entire MVC design pattern in itself. Hibernate, Servlets, and your Java Beans are your application tier. There are other Flex MVC frameworks as well. Check out this other stackoverflow article for alternatives: http://stackoverflow.com/questions/37043/flex-mvc-frameworks

The basic concept of Cairngorm is this:

1. Model: A singleton ModelLocator which stores the data that the Model needs to read from.
2. View: Your MXML/*AS* files that render the Model above.
3. Controller: The singleton FrontController that registers business events to a Command. The Commands represent a specific business logic task with associated logic/processing. This is usually where your API calls go to the Application tier to execute logic, fetch data, etc. When the Command is done, the Model is updated and your view will reflect those changes in the Model.

I could go in grave detail, but all of this information is described very well in the Cairngorm article linked above.