Dalibor Topic, Kaffe.org; Fabiane Nardone, Brazilian Health Care; Tony
Wasserman, Carnegie Mellon University; Ashlee Vance, The Register form a
panel of outsiders reviewing Sun's Open Source efforts. This session
isn't specific to Java ME technologies but is worth listening to as it
relates to open source as a whole.
autogenerator for primitive collections
2008-05-20 10:43:59 xxmhazi
[Reply | View]
Alex writes above that "three higher patterns of behavior ... can be observed in all existing systems":
Data source, action, and workflow.
It seems to me that the concept of MVC works so well and enough parts of it are already implemented for us that we are starting to take it for granted, and that Alex is just describing a web-specific sub-framework for the Model part of MVC. Let's look at MVC again:
MODEL. The model includes both data source and behaviors (doing something useful with the data). If you want actions and workflow to be manipulated by the user at runtime, then they are essentially complex data structures (which can include code as data) that belong in the model. oyun Storing and retrieving them to/from the data source is a responsibility of the model which we often delegate to pre-built systems. For example, my current habit is to use MySQL + JDBC + Hibernate in order to store my model's data. The other part of the model, behavior, represents what the application actually does so it would be typically written by the programmer. My current habit is to use POJOs to represent specific behaviors.
VIEW. Nothing in MVC says that the view has to be a computer monitor, as Alex implies. Plenty of existing desktop and web applications include support for a "print view", which is realized on paper or saved for later as PDF. The view is an abstract concept. oyun It can be implemented to be consumed by any of the senses - vision, hearing, smell, taste, touch. For example, if you've ever played a game console and felt the joystick vibrate when something explodes on screen, then you've experienced a view implementation for the sense of touch.
Back to web development -- since in web development the model is easily separated from the view (application and client) and since basic controllers already exist to tie them together (Apache,IIS,...), it's easy to misunderstand how our work fits in to this. The developer has choices:
Is the application being written for a thin client or a rich client? If it's a thin client such as a non-Javascript enabled browser, then the view code must be written for and run on the server platform (Perl,Python,Java...), and it must generate HTML that the thin browser can process for display. If the thin browser has sound, smell, and touch capabilities, the HTML can include tags for these. Don't want to change the HTML spec? Use the "object" and "embed" tags to reference the content for the senses. If it's a rich client such as an Ajax-capable or Flash-capable browser, then the view code can be written in JavaScript or Flash and run on the browser, retrieving only serialized data from the server, the serialized data being provided by the model, and this can be in any data format the developer wants... XML, HTML, WDDL, JSON, YAML, MPEG, Flash...
CONTROLLER. The controller is responsible for coordinating events that happen in the model and the view. In a desktop application it's easy to see that the controller is responsible for handling mouse events etc. It's easy to identify work that needs to be done by the developer to implement the controller. But in a web application, it's not so easy, because the controller code can be partitioned into several layers or components, and this partitioning depends on the architecture: thin clients such as browsers already process mouse events, such as clicking links and submitting forms, but there's usually more controller code to be written by the developer on the server in order to keep these details out of the model; whereas in rich clients the developer may be writing more controller code for the client in the form of a Flash or Ajax client-side application and writing less controller code for the server.
Alex writes that the "core concern of the servlet framework" is to manage data source, action, and workflow objects. If that's what he needs, then he's right to look for a framework that does that. But I disagree about the purpose of frameworks. oyunlar In my opinion, the purpose of a framework is to enable a programmer to concentrate on what is important. When using the MVC architecture, then obviously a good framework should make it easy to focus on just the interesting parts of the model, view, controller, or any combination of the three.
Struts works well as a controller framework for applications with a pre-determined workflow and actions, because you just configure the connections between actions and other actions or views in XML files and start writing code. Your code is in the form of actions, which are an interface to the controller framework, and your own model, however you like it.
Freemarker is a framework for generating text so it works well with thin clients that consume HTML in order to implement the view, such as a web browser.
Hibernate is a helpful framework for managing the data storage aspect of the model. If your application is designed so that actions and workflows can be manipulated at runtime, then those are just data in your model and you could use a business rules or workflow framework to help you manage that, such as Drools. In that case, you might still want to use Struts or another controller framework to manage the non-dynamic portions of your application.
If your design includes a rich client, then you may want to use a rich client framework such as Flex or GWT to create that client. The rich client itself may be designed with an MVC architecture, treating the external behavior of your server application as the model and implementing in itself the controller and the view.
You get to decide in your design if the client is both controller and view or if a server implements the model and controller and the client is just the view. After you decide, pick the frameworks that help you write just the interesting parts.
Alex notes that there are many good frameworks for views and that the web servlet framework shouldn't reinvent that. He also says that he is interested in applications where the workflow and actions are manipulated at runtime. So for Alex, the task is to find a model framework that will manage his data source and workflows, so all he has to do is write the actions and let the framework arrange them and provide access to data. Then he has to find a controller framework that will complement this nicely. By the way, that framework could still be Struts (or Stripes, etc). Then he has to choose one of the many available view frameworks.
So I disagree with Alex about what the higher abstraction is. I think MVC is a higher abstraction than his special case of a certain type of web application, because MVC also works for other web applications and for non-web applications, where as Alex's abstraction doesn't.
java.net RSS Feeds
