Best practice for separating application logic

Question

In my application Ive separated next levels of application logic:

1. Utilities
2. Application abstraction
3. Simple/common implementation of the application abstraction (#2)
4. Concrete application implementation (additional functions and classes to append #3 to fit our final application purposes)
5. abstract mvc application architecture (abstraction for mvc logic of application)
6. concrete mvc application

Description of these levels:

1. Utilities, libraries and so... (doesn't have dependence, maybe used by any concrete class of application)
2. Abstract classes of an application. Defines very abstract classes of application (doesn't have dependence)
3. Concrete classes of an abstract application. Defines commonly concrete classes of an abstract application (have dependence with logic level #2)
4. Concrete (final) application classes. Defines our finally classes for the concrete application model (have dependence with logic level #3 and #2)
5. abstract MVC architecture of application. Defines abstraction for our concrete MVC application (doesn't have dependence)

6. concrete MVC architecture of application: concrete controller, views, models. Concrete application workflow (MVC: views as view, models as proxies, controller to link both)

   • Models are simple Proxies that work with level #4 (dependence with #5 and #4)
   • Controller and view don't know about what classes model uses (doesn't have dependence with any level, except #5).
   • Model share data with view using "value objects" (defined in the logic #5)

Cars Game Application Example:

1. EngineUtils, TrackUtils and so

2. ICar, ITrack, IEngine, ITrackFactory, IEngineFactory and so

3. Car, Track, SimpleEngine, AdvancedEngine, EngineFactory and so (implement interfaces of #2)

4. HondaCar, FordCar, BMWCar, TorontoTrack, TokyoTrack, DushanbeTrack, KualaLumpurTrack, TrackFactory, SuperEngine, ExtendedEngineFactory and so

5. ITrackProxy, ICarProxy, CarVo, TrackVo, TrackListVo, CarListVo and so

6. GameController, TrackView, CarView, CarProxy, TrackProxy and so. Data sharing by model<->view are CarVo, TrackVo, TrackListVo, CarListVo and so

What do you think about this levels? And if its OK, Im thinking about how to separate all this levels in the project? (by namespaces or by libraries). If namespaces, then I have a problem of naming this namespaces...

Answer 1

This is very similar to how I currently manage projects (in any platform/language).

I tend to put Utilities in a separate project/library and give it a universal namespace, like com.yourdomain.Core or something like that. This library would then be created to be usable by any application, even outside Cars Games.

I think you can put #2 (abstracts) and #3 (common concretes) in the same folder/package/namespace/project as the abstract application library (#5). I'm thinking that no other project besides those of Cars Games will need a reference to abstracts and common concretes, so you might as well put them in the abstract application library. Otherwise, you can keep #2 and #3 together in one library, and reference it from the abstract application library.

In a concrete application, I would create the specific classes (#4), and reference utilities and the abstract application library (that would contain abstracts (includes interfaces) and common concretes).