tag:robotlegs.tenderapp.com,2009-10-18:/discussions/questions/222-package-structureRobotlegs: Discussion 2018-10-18T16:35:14Ztag:robotlegs.tenderapp.com,2009-10-18:Comment/22921522010-07-18T17:36:06Z2010-07-18T17:36:06ZPackage Structure<div><p>Hi Mike,</p>
<p>I go for</p>
<p>[com.domain.project]</p>
<pre>
<code>[functionalarea] <------ often representing a 'state' of the application like login or mainmenu
[api]
[events]
[vos]
[restricted]
[controller]
[commands]
[events]
[model] <------ Rarely have subpackages in here - generally split higher if there's more than a few classes
[services] <------ Rarely have subpackages in here - generally split higher if there's more than a few classes
[view] <------ Often have subpackages in here if my view is complex
[anotherfunctionalarea]
[api]
... etc</code>
</pre>
<p>Whether or not I'm compiling the functional areas into separate
swfs, splitting by function before type makes much more sense to
me.</p>
<p>Doing it this way also allows me to use FlexPMD to verify that
none of my restricted classes are used by other functional areas.
Only classes in the api package may be used by classes outside of
the functionalarea package.</p>
<p>If I have common functionality then I might have a functional
area package called 'common' or 'shared' with all those shared
classes in the api package.</p>
<p>There are 4 purposes to a package as far as I can tell:</p>
<p>One is about folders and browsing for code as a developer.<br>
A 2nd is about communicating the purpose of the package (by using
conventions). 'This is a model' etc.<br>
The 3rd is about restricting access using the package-access
modifier (internal).<br>
The 4th is about indicating to another developer (or myself) what
the relationships with other classes are likely to be. In the api
package? Great - use it in other functional areas ... etc.</p>
<p>I try to never make my package choices solely about number
one!<br></p>
<p>Obviously it depends on the size of your application and how
many classes there are, but if my application has significantly
different 'states' - to the extent that the user could recognise
the different states - then I generally like to separate these out
first and then split by mvcs. Or I might split my app by parts -
navigation, logging etc.</p>
<p>I think we forget how much cognitive overhead the package choice
can take care of when done well.</p>
<p>I'd be interested to hear how others do it.</p></div>Straytag:robotlegs.tenderapp.com,2009-10-18:Comment/22921522010-07-18T18:10:50Z2010-07-18T18:11:55ZPackage Structure<div><pre>
<code>[domain.lib]
various utilities
[domain.project]
[projectmodule]
[model]
[events]
[vo]
ProjectModuleStateModel
[view]
[events]
[renderers]
[skins]
MyProjectModuleView
MyProjectModuleViewMediator
[controller]
[startup]
MyProjectModuleActionCommand
[service]
[helpers]
MyProjectModuleService
IProjectModuleService
[projectmodule]
[model]
[events]
[vo]
ProjectModuleStateModel
[view]
[events]
[renderers]
[skins]
MyProjectModuleView
MyProjectModuleViewMediator
[controller]
[startup]
MyProjectModuleActionCommand
[service]
[helpers]
MyProjectModuleService
IProjectModuleService
...</code>
</pre>
<p>Should be noted that while this is broken down into "modules"
they aren't necessarily Modules. They CAN be, as needed. I actually
break my views down further with an interface for views as well as
a base class so that the final MXML is simply markup and not code.
This is pretty granular, but really improves testability on the
view tier.</p></div>Joel Hookstag:robotlegs.tenderapp.com,2009-10-18:Comment/22921522010-07-20T16:55:26Z2010-07-20T16:55:30ZPackage Structure<div><p>And how about signals? Do you still find the utility useful?
Does your project layout change when using signals instead of
events or just replace the package 'events' with 'signals'?</p></div>Daniel tag:robotlegs.tenderapp.com,2009-10-18:Comment/22921522010-07-20T17:29:56Z2015-10-19T23:47:52ZPackage Structure<div><p>Cheers for that Stray & Joel.</p>
<p>From what you have both said it seems that its kinda of personal
preference to a certain degree. You both split by MVC at a certain
level but then layout the other areas in different ways.</p>
<p>Daniel, I guess so mate. I like to use signals too. I have up
till now split signals from commands but im starting to wonder if
it not better to put the signal next to the command for easy
reference. <em>shrug</em></p>
<p>Mike</p></div>mike.canntag:robotlegs.tenderapp.com,2009-10-18:Comment/22921522010-07-20T17:36:12Z2010-07-20T17:36:12ZPackage Structure<div><p>I use signals - custom signals go in the controller package, so
it would then have commands / events / signals.</p>
<p>yes - project size makes a big difference, and also how you're
working. I'm in a team but I'm the boss and not a lot of code gets
written by others at the moment, so I can indulge myself :)</p></div>Stray