Lets imagine I have a complex software project with several major sections and each of these sections has a few resource types associated with it. There are two ways to organize the project.
I consider the first way to make the most sense. It keeps all the resources related to each section in a tight package. Everything related to each section is in one spot.
However, in this current project I am working on, which is a web app, the 2nd way, I have been told “Is the normal way it is done”.
What I want to know is, if the 2nd way is truly correct, and not just some arbitrary convention, what is the wisdom behind this design pattern? Why is it correct? What benefit does it provide that I do not see?
I’m with you. The first way seems to me to make more sense. And I think at the end of the day either way would work; I would bet people are saying the second way is “normal” because that’s the way they learned how to do it, or that’s the way the project was organized when they started. Instead of asking US this question, pose the question to those people - make THEM explain why the second way is preferred.
And though I think it doesn’t matter, I am open to hearing that I’m wrong and there is some awesome reason to organize such a project in a specific way!
To be more specific for the 2nd way, it would have all JSPs in one area, all HTML in one area, all images in another, etc… I didn’t originally put it that way because I wanted an unbiased opinion. It really puzzles me, but more than a few web developers think this is the proper way to do things. I just want to know why.
Dunno about web development specifically, but in a more general computer science sense, the second method would allow easier distribution of the resources onto platforms that are optimized for a specific resource type. I’ve used similar organization patterns in systems integration projects; for instance, corresponding to your resources, you’d have all the connections with your ERP system grouped together, all the connections with your CRM system together, all the canonical data object routing together, etc. You might have lots of different data flows that each used all three of those components, which would roughly correspond to your sections. That made it easy to put all the ERP stuff onto a platform that was “close” to the ERP system, where “close” could mean different things based on the architecture of that system…usually a VM in the same data center with minimal network complexity between it and the ERP’s server. I’m not a web developer so I don’t know if this makes the same type of sense in that context, but it gives you an idea of why that pattern might be useful.
For web content, the second option is what is almost globally used in project. Specifically, off the root you will see folders for ‘images’, ‘css’, ‘javascript’, etc. The reason is that a lot of these will be used globally throughout the site. For example, you’d want a jQuery right in root\javascript to be used everywhere. CSS style sheets will similarly be globally applied and not tied to any one section. Even for section specific content (say, images for your home page), it’s better to put them in images to act as a filter of sorts. My actual home.html can be a solitary file of HTML and not be stuck in a subdirectory called “HomePageContent.”
With all of that said, sections are useful for things like compartmentalizing code that accesses the database, business logic, service layers, etc. I usually put these in separate projects inside a Visual Studio solution. Each in turn gets compiled to its own DLL file and is often shared around the project between multiple spots. (Since it appears that you are using Java, I’m not sure of the proper terminology for your environment. But essentially, multiple roots depending on design of the application.)
