Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>What has worked well for me is large level grouping by type of code, but more macro-level than the logical units you were splitting up by. For instance,</p> <ul> <li>Engine - anything non visual. Support classes, base infrastructure code. Everything refers to this. </li> <li>EngineUI - Relies on Engine, and obviously used for UI, but nothing specific to any one app.</li> <li>EngineServer - Relies on engine, used by the (usually web) server build.</li> <li>AppCore - App specific core functionality, no UI.</li> <li>AppUI - App specific UI</li> <li>AppClient - Uses AppUI, AppCore, EngineUI, Engine. The actual client app.</li> <li>AppServer - Uses AppServer, EngineServer, Engine. The server app.</li> </ul> <p>Each project has a hierarchy of namespaces and once in a while I find its useful to fork out a large body of code into another assembly but usually these keep things reasonably organized and manageable, even when there are many hundreds of files involved. Too many projects is definitely something I try to avoid. One bonus of keeping these projects to a minimum is that it makes it a lot easier to actually reuse these libraries in subsequent projects (such as automated testing builds).</p> <p>I don't worry too much about unused code being deployed from these libraries because I can use a <a href="http://www.smartassembly.com/index.aspx" rel="nofollow noreferrer">utility</a> that strips out unused functions for the final build, keeping file size down to a minimum.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload