分离应用程序逻辑的最佳实践

Question

在我的应用程序中，我分离了下一级应用程序逻辑：

1. 实用程序
2. 应用程序抽象
3. 应用程序抽象的简单/通用实现（＃2）
4. 具体的应用程序实现（附加功能和类，以附加＃3以满足我们的最终应用目的）
5. 抽象mvc应用程序架构（应用程序的mvc逻辑抽象）
6. 具体的mvc应用

这些级别的描述：

1. 实用程序，库等...（没有依赖性，可能被任何具体的应用程序类使用）
2. 应用程序的抽象类。定义非常抽象的应用程序类（没有依赖性）
3. 抽象应用程序的具体类。定义抽象应用程序的通常具体的类（依赖逻辑级别＃2）
4. 具体（最终）申请类。为具体应用程序模型定义我们的finally类（依赖于逻辑级别＃3和＃2）
5. 应用程序的抽象MVC架构。为我们的具体MVC应用程序定义抽象（没有依赖）

6. 具体的MVC架构的应用：具体的控制器，视图，模型。具体的应用程序工作流程（MVC：作为视图的视图，作为代理的模型，链接两者的控制器）

   • 模型是简单的代理，适用于＃4级（依赖于＃5和＃4）
   • 控制器和视图不知道模型使用什么类（除了＃5之外没有依赖任何级别。）
   • 使用“值对象”（在逻辑＃5中定义）与视图共享数据模型

汽车游戏应用示例：

1. EngineUtils，TrackUtils等

2. ICar，ITrack，IEngine，ITrackFactory，IEngineFactory等等

3. Car，Track，SimpleEngine，AdvancedEngine，EngineFactory等等（实现＃2接口）

4. HondaCar，FordCar，BMWCar，TorontoTrack，TokyoTrack，DushanbeTrack，KualaLumpurTrack，{{ 1}}，TrackFactory，SuperEngine等等

5. ExtendedEngineFactory，ITrackProxy，ICarProxy，CarVo，TrackVo，TrackListVo等等

6. CarListVo，GameController，TrackView，CarView，CarProxy等。按型号＆lt; - ＆gt;视图分享的数据包括TrackProxy，CarVo，TrackVo，TrackListVo等等

您如何看待这个级别？ 如果它没问题，我在考虑如何分离项目中的所有这些级别？ （按名称空间或库）。如果是名称空间，那么我有一个命名这个名称空间的问题......

Answer 1

这与我目前管理项目（使用任何平台/语言）的方式非常相似。

我倾向于将Utilities放在一个单独的项目/库中，并为它提供一个通用的命名空间，比如com.yourdomain.Core或类似的东西。然后，即使在Cars Games之外，也可以创建该库以供任何应用程序使用。

我认为你可以将＃2（摘要）和＃3（常见的混凝土）放在与抽象应用程序库（＃5）相同的文件夹/ p​​ackage / namespace / project中。我认为除了Cars Games之外没有其他项目需要参考摘要和常见的混凝土，所以你不妨把它们放在抽象的应用程序库中。否则，您可以将＃2和＃3放在一个库中，并从抽象应用程序库中引用它。

在具体的应用程序中，我将创建特定的类（＃4），引用实用程序和抽象应用程序库（包含摘要（包括接口）和常见的混凝土）。