15

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.

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

5 Answers 5

11

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.

3
  • 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, 2010 at 20:11
  • @Michael i agree, but in this case it is a large project.
    – Zzz
    Nov 10, 2010 at 20:32
  • 1
    +1: And if you ever have to converse with a user/client, then the terminology can be fairly consistent. Nov 10, 2010 at 20:38
4

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.

1
  • +1 for common and general(every project has general utilities, tools...)
    – Zzz
    Nov 10, 2010 at 20:58
3

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.

4
  • 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. Nov 10, 2010 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... Nov 10, 2010 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. Nov 10, 2010 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. Nov 10, 2010 at 19:33
1

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.

1

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. :)

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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