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

Question

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

1. 实用程序
2. 应用抽象
3. 应用抽象的简单/通用实现 (#2)
4. 具体的应用程序实现（附加函数和类以附加 #3 以适应我们的最终应用程序目的）
5. abstract mvc application architecture (abstraction for mvc logic of application)
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、TrackFactory、ExtendedEngineFactory等

   >

5. ITrackProxy、ICarProxy、CarVo、TrackVo、TrackListVo、CarListVo等等

6. GameController、TrackView、CarView、CarProxy、TrackProxy 等等。按模型共享数据视图有CarVo、TrackVo、TrackListVo、CarListVo等

你觉得这个关卡怎么样？ 如果没问题，我正在考虑如何在项目中分离所有这些级别？ （通过命名空间或库）。如果是命名空间，那么我在命名这个命名空间时会遇到问题......

Answer 1

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

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

我认为您可以将#2（抽象）和#3（通用具体）放在与抽象应用程序库（#5）相同的文件夹/包/命名空间/项目中。我认为除了 Cars Games 的项目之外，没有其他项目需要对抽象和通用具体的引用，因此您不妨将它们放在抽象应用程序库中。否则，您可以将#2 和#3 放在一个库中，并从抽象应用程序库中引用它。

在一个具体的应用程序中，我将创建特定的类（#4）、引用实用程序和抽象应用程序库（将包含抽象（包括接口）和通用具体）。