views:

21

answers:

2

I have a php script that generates php and javascript wrapper classes that handle json marshalling based on a configuration file.

My initial plan was to have a single config file that generates all the classes used by the application. However, my team lead suggested I use a separate file for each feature, to avoid creating a gigantic config file, and create a directory that defines json objects that are shared by multiple features

I compared it to struts-config.xml where all the definitions are in one file. Another example is a data dictionary that is used to generate DB access classes and the SQL to generate those tables; in previous jobs, there was always a single file that defined all the db tables, so I didn't even give it much thought since that is what I was used to.

He compared it to idl (it's a lot like idl), and we do not hold all the idl definitions in one place.

So I'd like arguments for and against using a single file. Here are some:

Single file

  • Good

    • You can see all the json objects in one place (this is the core of our web API and it's used for documenting the server Ajax calls)
    • You only need a single makefile (or ant target)
  • Bad

    • File can be hard to edit once it gets too big

Multiple Files

  • Good
    • JSON only used for a single feature is not exposed (private to a project)
  • Bad
    • Once a JSON object is used by two features, it needs to be moved to a different file

Any feedback is appreciated and please ask me to clarify if you want to chime in but are not quite sure what I am talking about.

A: 

Programming or not I think the below principles are good suggestions. So apply these two to your situation and you will answer yourself ;-)

Single Responsibility Principle Cohesiveness: Group related things together

Pangea