Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

The project, I have involved, has an architecture-oriented project's file/folder structure:

Root
|____ Node1
    |____ Event Handlers
    |         |___ <all event handlers of project>
    |____ Events
    |         |___ <all events of project>
    |____ Request Handlers  
    |         |___ <all request handlers of project>
    |____ Requests
    |         |___ <all requests of project>
    |____ ...

It is a clear from the architectural point of view of system (has been proposed by development team).

It is a feature-oriented structure has been proposed by designer team:

Root
|____ Feature #1
    |____ Event Handlers
    |         |___ <all event handlers of Feature #1>
    |____ Events
    |         |___ <all events of Feature #1>
    |____ Request Handlers  
    |         |___ <all request handlers of Feature #1>
    |____ Requests
    |         |___ <all requests of Feature #1>
    |____ ...

This variant is closer to designers and it describes clearly a feature to be implemented.

Our teams have started a holy war: what is the best approach. Could somebody help us and explain cons and pros of the first and second ones. Maybe there is a third one that is more useful and beneficial for both of us.

Thank you.

share|improve this question
    
I don't understand either structure - what's the difference between Events and Requests (and thus Event Handlers and Request Handlers)? –  Peter Boughton Nov 10 '10 at 20:11
    
Very clear question - and neutral too! –  Michael K Nov 10 '10 at 20:11
1  
From the scalability perspective, the second approach should be fairly easy to scale out horizontally. –  CodeART Nov 25 '13 at 13:39

5 Answers 5

up vote 8 down vote accepted

I would vote for the second one. In the first structure, event handlers for FeatureA are completely unrelated to event handlers for FeatureB. It seems that developers will be working on one feature at a time, and if you're working on a FeatureX request, it's far more likely that you'll need to tweak a FeatureX request handler than, say, a FeatureZ request.

By the way, I love how you asked this question from a neutral point of view.

share|improve this answer
1  
+1 with one caveat: for small projects, the second will result in a larger file structure than there are files to put it in. I'd use the first for those. –  Michael K Nov 10 '10 at 20:11
    
@Michael i agree, but in this case it is a large project. –  Zzz Nov 10 '10 at 20:32
1  
+1: And if you ever have to converse with a user/client, then the terminology can be fairly consistent. –  Steve Evers Nov 10 '10 at 20:38

Why do the feature-inventors care about the implementation details? If that is the separation between the sides of the argument, then I think the answer is clear. People inventing ideas/features do not determine the file structure that is needed by the implementers.

This is a particularly important issue when a feature's implementation spans multiple dlls, exes, databases, or other software pieces.

share|improve this answer
1  
I thought about that, but, all other things being equal, the second approach has some clear philosophical advantages for all but the most trivial of applications. At the very least, it's a good suggestion. –  Robert Harvey Nov 10 '10 at 19:17
    
@Robert Harvey: If you're talking about the idealogical organization of the project, then I would need to think up a new answer. However, it sounds like they're talking about files containing code... –  John Fisher Nov 10 '10 at 19:18
    
The key is the separation of features into distinct buckets. For all but the smallest of applications, you are going to need some kind of organization like this, whether you are referring to a folder structure, a class structure or a namespace convention. –  Robert Harvey Nov 10 '10 at 19:20
1  
@Robert Harvey: What about build and deployment issues? How about simpler things like merely being able to use an IDE to write and debug the code? Some of these things should have a powerful impact on the folder structures. –  John Fisher Nov 10 '10 at 19:33

I have always been more comfortable with the second approach, but I always have a "feature" called general or common for the truly shared/base classes.

Approach two keeps truly separate things separate, but without the "common" area it sometimes separates things into areas that they don't fit well.

share|improve this answer
    
+1 for common and general(every project has general utilities, tools...) –  Zzz Nov 10 '10 at 20:58

Have to agree with the second approach, given the two options. The first one just looks like an amorphous blob. At least the second one has some shape.

It really depends on how big the project is. If the "features" are large, they each need their own distinct bucket.

share|improve this answer

I don't understand the terminology you're using, but will try to answer anyway, since both structures seem to be the wrong approach.

Unless you've only got a handful of features, you need to group them into categories - and that doesn't appear to be catered for in either design (unless that's what Node1 is intended as, but the "all X of project" suggests otherwise, and makes me wonder WTF it is - is there a Node2?)

I might consider something like this:

Root
|____ Event Handlers
|   |____ Category A
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Category B
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|
|____ Events
|   |____ Category A
|   |    |___ Feature #1 Events
|   |    |___ Feature #2 Events
|   |    |___ Feature #3 Events
|   |
|   |____ Category B
|   |    |___ Feature #4 Events
|   |    |___ Feature #5 Events
|   |
|

Or this:

Root
|____ Category A
|   |____ Event Handlers
|   |    |___ Feature #1 EHs
|   |    |___ Feature #2 EHs
|   |    |___ Feature #3 EHs
|   |
|   |____ Events
|        |___ Feature #1 Events
|        |___ Feature #2 Events
|        |___ Feature #3 Events
|   
|____ Category B
|   |____ Event Handlers
|   |    |___ Feature #4 EHs
|   |    |___ Feature #5 EHs
|   |
|   |____ Events
|        |___ Feature #4 Events
|        |___ Feature #5 Events


But they're both making assumptions which may be completely off - if you can update your question with more details I may change my mind. :)

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.