I have added a new demo. This one showcases the new CVS features in NetBeans 5.0 Beta and shows how easy it is to checkout a project and work with files under CVS control. This demo is just over 4 megs in size (they are slowly getting smaller 
). Enjoy and let me know what you think.
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.
Here is a very quick rundown on what each term in the MVC pattern means:
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?).
Here is a quick example: A user login page.
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.
There is a post on the live journal website that does an excellent job of discussing the proper way of understanding test-driven development.
“Test”, in Test Driven Development, encapsulates the idea of specification, design, verification of implementation and the ability to confidently refactor. Regression testing itself is almost a by-product of these uses of the word “test”.
In my experience, this can be the hardest part thing to get people to understand. On the other hand, one person in the comments states that the problem is really a lack of understanding of OOP. I find myself agreeing with this. On the other hand, should TDD not be paradigm independent? Should it not work for both OOP and procedural programming? Or is it tied directly to the Object-Oriented world?
I really like the idea of exchanging the word “test” for the word “should” for the name of your tests.
Don’t test; think “What should this class do? What are its roles and responsibilities? What does it do to the things I’m going to give to it?” Then write a method which will describe the class’s behaviour.
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 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.
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:
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.
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.
