views:

67

answers:

1

I've been writing a web application for the past year or so and I've got a feeling I've structured it in a poor way but I'm not really sure what it should look like.

The application models logistics so currently has two main parts - geography and network.

Domain + Business layer

I have separated the network and geography in 2 separate projects containing their domain, persistence and business logic. There is also a service layer that wraps transactions around calls to the DAOs so that it can be later called by web services.

Presentation Layer

I have one project that has the controllers, JSPs, javascript, css etc. I'm not sure if this was the right thing to do. The javascript makes calls to the Web Service Layer using DWR.

Web Service Layer

I think this is where I've really gone wrong. There is a single project for the web services that contains instances of the service layer objects from the Network and Geography projects.

Why I think I've gone wrong

I'm about to add another segment to the application which queries salaries from a legacy system and displays the data on a web front end. Initially I was going to continue with the same approach as above:

  1. Implement a domain/dao/service project
  2. Add web services to the web services project to query the new domain project
  3. Creating the view in the presentation layer project.

I feel like it is such a separate part of the application that it should be much more loosely coupled.. I had a read about SOA, the principles sound really good but I'm not sure how to get there. My thinking is to create a single project for this new segment which contains all of the tiers so it's completely standalone. Is this what I should've done all along?

Any advice would be greatly appreciated.

A: 

A fairly tradition EAR structure that wraps up your presentation layer (which would be your WAR, which can be a separate project if you like) and your core business logic/DAO layer (your single JAR).

The web services get a little more interesting as you're really offering up a public API for others to access. For example you might want to split out your web services layer into a separate project so you can release version 1.2 of your web services to sit alongside your version 1.1, both of which are compatible with your 1.1 core.

All in all it really just depends (no pun intended) on what dependencies you want these various parts to have on each other. If you do end up splitting them out I can recommend Maven or ANT/Ivy to help you structure this.

karianna
Yeah. I would only split out separate projects if there is an actual need, not just to insulate a project from itself. I think that a publicly released web service api is a valid reason to do so.
Peter DeWeese