Web Application Project Structure

Having done this stuff for over a decade, here is the current best organization of code I’ve seen for a large enterprise type project (it will work just as well for small projects).

Btw, I should mention this is based on an architecture of fat client / thin server, but ability to shove off processing to one or the other. The server and client exchange information via JSON, XML, etc. The server does not render html. The servers job is to pull and maintain data in a centralized location, not to render html pages.

First, the server side;

config - This folder provides context and environment for your application to run. Database settings, log settings, AOP and Injection and Beans.

domain - This folder provides the persistent data model of your application. Typically what gets mapped to tables. Interchangeable with the word ‘model’ this is where your Persistent POJOs go. And no, I’m not a fan of the active record pattern. Btw, enums and constants are part of the domain.

services - The services layer has long been a staple. Historically know for it’s SOAP like handling. But, in our case, we use this for XML and JSON (and AMF3). The services layer should take in a set of defined parameters or a DTO (data transfer object) and return a DTO. The DTOs are defined in the services layer, because they are explicitly used by the services. DTOs are nothing more than encapsulations of domain objects and properties that don’t fit the rudimentary crud pattern. Thing reports and dashboards. I should also mention, the services layer should NEVER be doing translation. Again, use AOP to intercept the input and output to fit your service layer’s needs.

dao - The repository pattern fits into here. Note, this is unnecessary if you’re using the active record pattern, but I prefer to conceptually and architectually consider the dao where things go to be stored or removed from the store. Models are data defined by classes of encapsulated properties, not dao. But, I do understand the reason for the Active Record pattern. It is a reasonable assumption and works well, but I prefer dao. FYI, I have precisely two dao classes in my java backend. One for CRUD and one for Querying data. Don’t make daos for each domain object. That’s insane. Use AOP and intercept calls.

utils - Static classes or classes which don’t fit into a particular mold (ie not a service, not a dao, not a model, not a config). These classes should have as few dependancies as possibly on any particular layer and should be reusable.

scripts - migrations, testing, etc. Something that will not run on the server, but should instead be run at development time to achieve something. I suppose testing could be it’s own file, but…

Second, the client side;

config - Again, given context to the client side app about what environment it is in and how it should run. Configure your injections and AOP etc.

domain - Again, this could be called the model, but I prefer domain. Ideally, your server side domain should map to your client side domain one to one. Use a generation tool of some kind.

services - These map requests from the client to the server. These could also potentially be generated from your server services folder. It should be mention that it is occasionally helpful to put classes which are essentially services, but don’t call a service or call a different service. Just so your controllers aren’t trying to do too much thinking. Controllers react, not think.

controllers - These handle actions that take place on the view. Navigation, a button click, a drag and drop. You should not reference any view type things in the controller. The view is driven by the controller, not the other way around.

views - What is actually shown on the screen. These should be as logic free as possible. This is the designers area to make things look nice, don’t clutter up his / her design with your programming.

taglib - components, renderers, reusable ui code, skins, validators, etc. These items should be as reusable and flexible as possible. And of course, these don’t rely on the view at all.

utils - Again just stuff that is static. Helper methods. StringUtil, NumberUtil, FormatUtil, FormUtil, etc. No context.

(flex specific)
assets - These hold your images, javascripts, styles, etc


Now, that is a flex application client side. HTML based changes things slightly. Nevermind, haven’t thought this one through enough… Will revisit.

/ - views
/images
/css
/
/js/domain -
/js/controllers
/js/utils
/taglib







Published by and tagged Architecture using 767 words.