When you break from the namespace/folder convention, do you have an alternate convention you like to use?  Is there a reason you don't want the extra namespace?

One reason I like the folder/namespace convention is that it can be easier to discern the project structure from looking at the solution explorer.  A project I inherited worked out so that assembly name != root namespace != project name, which led to several different root namespaces.  When I wanted to add a class, I had no idea where to put it (the app is a big ball of mud already), as just about every file in a folder had a different namespace.

Doesn't Java force package structure to match physical disk structure, too?

Hey, that's a pretty cool trick I didn't know about. However, the property doesn't seem to appear for me when I select folders, what's the trick? (R#?)

This is also helpful to control the names of embedded resources.

Don't forget the associated keyboard acellerators to make this happen:

ctrl + alt + L = Got to Solution Explorer

shift + arrow up/arrow down = Select folders

F4 = Switched to the Properties tab

Arrow down = Go to Namespace Provider

Tab = Edit value assignment

My 2 cents.  :-)

Folders as namespaces gives you a structural representation of a logical grouping. Otherwise, you must do a lot of mental mapping based on specialized knowledge - it's just more work for your brain.

I like splitting a namespace across assemblies, where each is a feature rooted in the same default namespace.

It achieves logical grouping and physical alignment, and merges nicely when a developer opts-in via a reference at the project level.

@dave - fair enough.  :-)

I didn't suggest a namespace per presenter. That's akward. I agree they should all reside in "Project.UI.Smart.Presenters".

I am saying you can accomplish this while still using namespace folders. You don't have to break from convention and you get all your requirements met.

Let's be concrete: it looks like you have 3 "nouns" per presenter: itself, the callback interface, and the view interface. So "Users" would expand to something like

Users\Add\[3 things]

Users\Modify\[3 things]

Users\List\[3 things]

As they all end up in the same namespace, the identifiers have to be unique for each thing.

Let's view this from the problem domain. The feature you are implementing is the presentation of user management. That is the logical grouping we want to convey - not the CRUD operations.

So let's group all user presenters in their own assembly:

UserManagementPresentation.csproj (default namespace Project.UI.Smart.Presenters)

UserAddPresenter.cs

UserAddCallback.cs

UserAddView.cs

UserListPresenter.cs

UserListCallback.cs

UserListView.cs

UserModifyPresenter.cs

UserModifyCallback.cs

UserModifyView.cs

This is a nice tight file list which, when referenced, will merge into the Presenters namespace along with any other assemblies written in the same pattern.

With 100+ triads, you have 300+ things to keep in the same place, and that is going to get unwieldy no matter what technique you use to organize it. Because you have chosen "what it is" and not "where it's relevant" as the distinguishing factor, you have a potentially infinite list requiring ever-more-subtle distinctions to keep all the names unique.

I write a lot of APIs, and my organizational mantra is "group by function not form". Sure, you have all your presenters in one place, but what, in concrete terms, does that buy you?

The function of each triad is scoped to a particular kind of "thing". Why not have "Presenters" folder underneath the relevant "thing" folder? e.g.

\Project\UI\Admin\Users\Presenters

\Project\UI\Admin\Roles\Presenters

\Project\UI\Portal\Blog\Presenters

It makes more sense to me to have all things relevant to \Users scoped to that folder, rather than know "this kind of thing is here, and this kind of thing is over here, and this kind of this is back here", etc.

Is there some perceived benefit to having all presenters in the same place?

I can't see it - is it a ReSharper thing?  Or VS2008?  neither of which I have :(

It's a ReSharper feature.

We disagree in our definition of function. I am referring to the ultimate function of any specific class, not of the general system or any base class.

As such, I define it as "Presentation of user management", where presentation is the form and user management is the conceptual domain. Form + domain = function.

In your approach, you have to *know* that all presenters are in one location. That knowledge and location are proprietary to your solution. It's a convention, so probably a no-brainer for you. But, when someone new comes along, they must be explicitly told that. The discoverability is low, though *ostensibly* it's higher.

In my approach, presenters appear wherever they are relevant. Want to know what presenters are in effect for users? They live right next to _everything else_ that's user-related. If someone comes along in a vacuum, they are easily able to discover that users have relevant presenters.

It's a bigger design philosophy: I am more apt to have 10 kinds of things relating to users all in 1 place, than I am to have 10 different places in each of which 1 thing relevant to users appears.

Partition your code based on the business problem domain, *not* the coding problem domain.

There is a jump in your logic which I think hints at the differences in our perspective. When faced with

"I want to control how user details are presented."

you think

"ok, i guess i need to be dealing with presenters and views."

and I think

"ok, I guess I need to be dealing with users."

In your question, "user details" comes before "presenter". Presenter is an aspect of user, not vice versa. You can't have a presenter before you have something to present.

So, if I'm new to your system, I will most likely know about users because I'm asking about them. I might not know about presenters. So, if they are not bundled with users, discovery of presentation logic happens via trial and error or explicitly being told.

The logical issue is that definitions of presenters and their aggregation are 2 distinct concepts, but are tied together when they must reside in the same namespace.

Process orientation is a concern at the aggregate level. You achieve that via configuration, i.e. "now that I have these different presenters, located where they are most relevant, I shall notify some central component of their existence."

No worries.

The rails conventions are rooted in a scripting mentality, where all-encompassing directories make managing includes less painful, among other things.

It comes down to grouping artifacts by their roles in the mechanics of the web solution versus their roles in the business problem. The structure of model/view/controller isn't going to change; you're resigned to stuffing more and more things in the same boxes, which doesn't scale. This very post is about a circumvention of established convention, via a 3rd party tool, combined with tacit knowledge, just to make it manageable.

Separating things out by "what they are" is a more industrial, brute-force approach, whereas "put things where they are relevant" is a more organic approach that scales with the problem domain.

Pingback from  » Daily Bits - December 19, 2007 Alvin Ashcraft’s Daily Geek Bits: Daily links plus random ramblings about development, gadgets and raising rugrats.

I just created my blog recently, but haven't posted anything yet. Perhaps I have my first topic: Function = Form + Business Problem. I'll be sure to pingback once I write it up.

In the meantime, there is an analogy which may help orient you to my thinking. What we have described is a composition to the solution of presentation of user management: several components of different types which, when used in conjunction, produce the desired result.

This sounds much like the web paradigm of .aspx, .css, and .js files, which "team up" to produce the desired page. Let's explore each of our organizational schemas by applying them to this similar problem.

In the "what they are" strategy, we're segregating by component type, so we'll make \CSS\, \ClientScript\, and \Pages\ folders. Already this sheds some light: does it really make sense to have a "Pages" folder? Aren't pages better organized by what they do, not what they are? Aren't they analagous to your presenters?

Once we have the structure, let's populate it with 100 pages (triads). To create a triad, I must put things in 3 separate places. To delete a triad, I must also visit those same 3 places - hope I don't forget one!

Now, with 3 folders and 100 files per folder, I can easily find where all my CSS is - but, finding that one exact file I'm seeking proves a bit harder. This can be alleviated by decoupling folders from namespaces, but now I have more folders to sift through, another arbitrary organizational line of thinking to follow, and that pesky ingrained namespace convention that makes understanding all of this that much harder!

In the "where they are relevant" strategy, we'll have a single top-level folder, \Users\, which contains all relevant user pages, CSS, and client-script. You don't have to go anywhere to find all relevant components, and if you remove the "User" concept by deleting the folder, there is no danger of increasing code rot by leaving a file around. No tacit knowledge is required and you still get folder namespacing.

If I'm making a cake, I don't go to 1 grocery store for milk and another for eggs.

(I realize that .css files should be in a theme directory with .skin files. This was illustrative only, and the "where they are relevant" concept still applies: styling information isn't relevant to user page *structure*. Themes still group different component types under a common goal - you don't implement them in "App_Themes_CSS" and "App_Themes_Skins")

I also forgot to mention that a structure of

Services/

Presenters/

Views/

Adapters/

Commands/

That only only tells me the kinds of things in the web solution, not what they *relate* to. I'm a web developer. I know there will be commands, adapters, presenters, etc., in a web solution, and I know how to handle them when encountered. Most likely they will have a suffix that lets me know what they are.

I want to know what *problem* is solved, and I can't get a good gut-feel idea without arbitrarily picking code to read.

> no, but you do go to one grocery story with multiple aisles ;)

I tripped up on the analogy. It should have been phrased as:

"If I'm making a cake, I don't go to the milk store and the egg store." :-)

I'll post something over the holidays.

Did all my Christmas shopping today. The shops were really busy. And now I don't feel like commenting

Interesting discussion, as always the best bit about any blog entry is in the comments!

@Bryan

Personally I can see a lot of what your saying, but I'm looking forward to the example. I'm also quite comfortable with the approach David uses though and to me the main thing about folder structures is that you'll never come up with one that everyone is happy with or that is right for every situation.

@Dave Laribee

When you say "my preference is to use a single studio project (per logical layer)" do you mean you'd only have one domain project? If so do your subdivide your domain (CRM/Ordering/Finance) by namespace?

@Colin - Yes. Some (not entirely strict) combination of namespaces, facades, and anti-corruption layer are how I implement the "module" pattern from DDD. We have a number of models in various projects. Our document management product has three models: Metadata, Workflow, and Security. We use the aforementioned technique. For larger problems I'm looking at Udi's NServiceBus as a cornerstone for a context mapping between many models. In this case (where models are connected by a bus) I'd peel the models off into separate projects.

@David

Interesting. We could certainly have used namespaces and I know some people recommend that but I don't think they are the most natural way to handle depdendencies. Facades I can see, anti-corruption layers though are not always appropriate when you are talking about multiple modules within a single bounded context.

Our approach so far has just been to have seperate domain projects e.g. Ordering/Crm/Finance. We aggressively look at coupling between these domain modules. So my question is whether when you just use one project do you really get the main advantages of modules in terms of managing complexity.

Seems interesting though, you thought of blogging about it? :)

Thank you Code Campers! I had 120 out of 400 of you (ASP.NET MVC was at same time) and you were a great

The other day, I found myself creating a bunch of new NHibernate object mapping files for the project

I create all of the code in my computer plantform very good character everthing is coming in my computer

ALPHA COMPUTER POWER DATABASE

Pingback from  agile.codebetter.com/.../folder-namespace.aspx

Thank you Code Campers! I had 120 out of 400 of you (ASP.NET MVC was at same time) and you were a great group. I had a great time with a new talk. Remember - just say no to RPC and Request/Reply - embrace the diversity of Asynchronous Messaging and Event

I tripped up on the analogy. It should have been phrased as: "If I'm making a cake, I don't go to the milk store and the egg store.