私のアプリケーションでは、次のレベルのアプリケーション ロジックを分離しました。
- ユーティリティ
- アプリケーションの抽象化
- アプリケーションの抽象化のシンプルで一般的な実装 (#2)
- 具体的なアプリケーションの実装 (アプリケーションの最終的な目的に合わせて #3 を追加する追加の関数とクラス)
- 抽象 mvc アプリケーション アーキテクチャ (アプリケーションの mvc ロジックの抽象化)
- 具体的な mvc アプリケーション
これらのレベルの説明:
- ユーティリティ、ライブラリなど... (依存関係がなく、アプリケーションの具体的なクラスで使用される可能性があります)
- アプリケーションの抽象クラス。アプリケーションの非常に抽象的なクラスを定義します(依存関係はありません)
- 抽象アプリケーションの具象クラス。抽象アプリケーションの一般的な具象クラスを定義します(論理レベル #2 との依存関係があります)。
- 具体的な (最終的な) アプリケーションクラス。具体的なアプリケーション モデルの finally クラスを定義します (ロジック レベル #3 および #2 との依存関係があります)。
- アプリケーションの抽象 MVC アーキテクチャ。具体的な MVC アプリケーションの抽象化を定義します (依存関係はありません)
アプリケーションの具体的な MVC アーキテクチャ: 具体的なコントローラー、ビュー、モデル。具体的なアプリケーション ワークフロー (MVC: ビューとしてのビュー、プロキシとしてのモデル、両方をリンクするコントローラー)
- モデルはレベル #4 で動作するシンプルなプロキシです (#5 と #4 に依存)
- コントローラーとビューは、モデルが使用するクラスを認識していません (#5 を除き、どのレベルにも依存しません)。
- 「値オブジェクト」を使用してモデル共有データを表示 (ロジック #5 で定義)
カーズゲームのアプリケーション例:
EngineUtils
などTrackUtils
_ICar
、ITrack
、IEngine
、などITrackFactory
_IEngineFactory
Car
、Track
、SimpleEngine
、AdvancedEngine
などEngineFactory
(#2 のインターフェイスを実装)HondaCar
,FordCar
,BMWCar
,TorontoTrack
,TokyoTrack
,DushanbeTrack
,KualaLumpurTrack
,などTrackFactory
_SuperEngine
_ExtendedEngineFactory
ITrackProxy
、、、、、ICarProxy
などCarVo
_TrackVo
_TrackListVo
_CarListVo
_GameController
、、、、など。TrackView
_CarView
_ モデルによるデータ共有 <-> ビューは、、などです。CarProxy
TrackProxy
CarVo
TrackVo
TrackListVo
CarListVo
このレベルについてどう思いますか?それでよろしければ、プロジェクト内のすべてのレベルを分離する方法を考えていますか? (名前空間またはライブラリによる)。名前空間の場合、この名前空間の名前付けに問題があります...