Meaning, my finders and services are in a separate layer from the classes for the objects they find, should my directory layout reflect this layering and if so I'd like to see an dumbed down example of how this is done
I'm repeating what is already known, but for the sake of conversation, lets say service locators and such are by their nature in separate layers, so I understand that. Your models use these 'services' such a locale objects?
You want to reflect that layering or relationship in the directory structure, or your asking whether you should or shouldn't?
IMHO conceptual layering and file system structure (while similar in many ways) I think represent two different paradigms of software development. File systems are innately strutural, whereas layering is typically conceptual and more flexible...
The OSI layers for example, should have little knowledge of those under them (except the next in line) and certainly shouldn't have knowledge of those above it. Of course in real life, perfect layering is a pipe dream and coupling does exist.
A structured file system on the other hand doesn't really dictate (implicitly or explicitly) any relationship(s) it's main focus in organization. Whether that organization is hierarchial is entirely up to the implementor. I personally have tried organizing my file system so base classes were root files and sub classes were in sub-directories...that didn't work well.
Likewise I have tried having the facade/interface reflected as root files and the derived classes located in sub-directories. While this worked a little better, it still not perfect.
Personally I keep my classes in an organization like:
Being in a single directory one might think they are 'layered' unfortunately I don't have direct control over the direction in which those files are displayed so I cannot say this one comes first, this one second, etc.
The work around (ie: Linux) is to use a convention that allows control over the ordering by prefixing file names with numbers like:
I think in this case...it works awesome (because it represents execution order not layering per se) but at the source code level trying to express layering using the file system would be a struggle to say the least.
Consider the example I just gave with models...
If models relied on a data access layer I might reflect that setup in the directory structure like so:
Code: Select all
models/
account.php
person.php
dal/
account.php
person.php
Now the file system indicates the relationship implicitly but it's core focus is still organizational. What this might lead you to believe is that all sub-layer dependencies of the model should be within the sub-directories like the DAL. But what about service objects like Locale? Or Authorization?
Those are system services and should obviously not be stored in the model directory. They are IMHO best left for their own directory 'services'.
I find mysef constantly asking these kind of questions, so it's certainly of interest to me, that is assuming I understood your question in the first place.

But even if I didn't it's always fun to braind dump ideas or thoughts to help cement them in my own head.
Cheers,
Alex