Archive for the 'Articles' Category

Java 101: MVC model2

So what exactly is MVC? In short, it stands for Model-View-Controller and it is an implementation of the layered architecture I was talking about in my first Java 101 entry.

Overview

Here is a very quick rundown on what each term in the MVC pattern means:

  • Model – this represents the business rules that you are trying to code. Another way of looking at it is that the Model is what does all the work. It is what performs any and all transformations on the data that your application is required to handle.
  • View – the view represents what the user sees and it is responsible for the collection and display of data for and from the model.
  • Controller – the controller is what ties everything together, it is the link between the view and the model.

One way of looking at MVC is that the user views a web page which displays and/or collects data. When the user submits this page, it is submitted to the controller which knows what to do with the data collected by that page. The controller does not know how to transform the data, but it knows which part of the model contains this knowledge and passes the data onto the model. The model then transforms the data. The controller, based on whether the transformation was a success or not, determines which part of the view to call and returns to that view a piece of the model in order for the view to display more data to the user. (Did you follow all of that?).

An Example

Here is a quick example: A user login page.

  1. The user sees the login page with a form that contains a field for the username and the password.
  2. The user fills in this data and submits it to the User controller with an action of login.
  3. The User controller knows to pass this information on to the loginDAO which attempts to verify that user against the database.
  4. If the user exists in the data, the model instantiates a User object and returns that object to the controller.
  5. The controller then tells Tomcat to load the homepage and sends the user object to the resulting jsp page.
  6. The view then shows a nice little “Welcome back Sue” message for the user to see. The name in the message comes from the user object.
  7. If the user does not exist in the database, the model returns an error and the controller instantiates the error page with an appropriate message to the user.

The general idea behind the MVC pattern is to abstract and remove as many dependencies as possible from between the layers. If done correctly, the entire web interface could be removed and a Swing ui could be put in its place with no code modifications needed on the part of the model. You may need to code up a few different controllers, but the model should not have to change. Likewise, you should be able to replace the entire model without having to change the view. This is accomplished because the point of dependency is the controller which sits in the middle.

I have listed a few links below for more information.

Reference

Java 101: Layered Architecture

I am going to try and start writting a series of very short tutorials on some of the things that I had trouble with when I was learning enterprise Java. The first of these is on what having a Layered Architecture means and why you should implement one. Hopefully this will be the first article in a series.

Layered Architecture

Layered Architecture is a term that you hear all the time in the world of Java, but what does it mean? In a nutshell, it is about putting code into layers—one layer for all the presentation code, one layer for the persistence code, one layer for the business rules, one layer for the object model, one layer for services, and other layers. It is a way of organizing your code that carries several benefits when done correctly.

Organized Code

Why can’t I just put all my code in the same place? This works well for a few classes, but once you have a few more classes, and then a few more, and a few 100 more, you need to organize those classes somehow. Layers is one way to do this. In Java, teh word layers translates to packages. So, in order to create these layers, you simply put your code into different packages. As an example, you could create a package called com.foo.presentation and put all your presentation code into it. Here is an example list of packages for a new application:

  • com.foo.presentation
  • com.foo.business
  • com.foo.persistence
  • com.foo.objectmodel
  • com.foo.services

Abstraction

The better reason for organizing your code into layers is for abstraction and encapsulation. This allows you to keep dependencies at a minimum and allows you join the layers through abstraction instead of through direct instantiation. Basically this means that you persistence layer can exist independently of any of the layers above. And the layers above call the code in the persistence layer through an interface instead of through concrete classes. In a component diagram, this means that you would have dependency arrows going down through the layers instead of both ways. Below is a diagram showing what I mean.

Component Diagram of a Layered Architecture

As you can see from the diagram, all the arrows either travel down through the layers or to the two side layers. These downward arrows represent the direction of dependencies through the application. The advantage of this is that if I build an application correctly, I should be able to swap out any of the layers and replace with entirely different code without breaking any of the other layers. So for example, if I am using Hibernate as my persistence layer, if I set up the correct interfaces I should be able to swap in something like Top Link or iBatis and DAOs and the entire application should continue to work. This is the power that a layered architecture gives you.

This is a very simple introduction to the concept of layered architecture, there are entire books that can be written on the subject. The best of which is probably Applying UML and Patterns : An Introduction to Object-Oriented Analysis and Design and Iterative Development (3rd Edition) by Craig Larman. This is one of those books that every software developer should read. It introduces not only Object-Oriented analysis and design using UML, but also design patterns and speaks at length about layered architectures in software development.

Feel free to leave comments on what I have written. If you have questions or issues with/about what I have written, please let me know through the comments section.

Resources and Links

Securing your Linux box

Everyone knows that Linux is secure, but this does not mean that your computer is uncrackable. Even though Linux is more secure than Windows, there are still things you can do to prevent your computer from being attacked and to prevent your computer from being compromised. This article is going to list a few things that you can do to help secure your Linux computer against an SSH attack from the outside.
Read more »

How to do: Group Based Authentication and Authorization

Someone on The List asked how to setup what they called “Multi-level login security”. Many Content Management Systems these days have this very feature. They will have a few people who are Administrators and can access everything on the site, another group of people who are editors who can only access a few things and then you have authors who can only submit stories and edit their own stories. In addition, this type of security needs to allow uses to be moved from group to group while keeping this totally transparent to the user. The question is though, how do you set this up on your site? This is actually not that hard to do. It takes three database tables and a little bit of forethought. We will start with the theory behind this simple technique, move on to the database tables, and end with a simple way of implementing this on a web site.
Read more »