分离应用程序逻辑的最佳做法

Question

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

1. 公用事业
2. 应用程序抽象
3. 应用程序抽象的简单/通用实现
4. 具体的应用程序实现(附加 #3 的附加函数和类以满足我们的最终应用程序目的)
摘要 MVC应用
5. 架构(应用MVC逻辑的抽象)
6. 混凝土中压机应用

这些级别的说明：

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、SuperEngine、ExtendedEngineFactory等

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

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

您如何看待这个级别？ 如果可以，我在考虑如何在项目中分离所有这些级别？(按命名空间或库)。如果是命名空间，那么我在命名此命名空间时遇到了问题......

Answer 1

这与我目前管理项目的方式非常相似(在任何平台/语言中)。

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

我认为您可以将#2(摘要)和#3(公共混凝土)放在与抽象应用程序库相同的文件夹/包/命名空间/项目中。我认为除了Cars Games之外，没有其他项目需要引用抽象和通用具体内容，因此您不妨将它们放在抽象应用程序库中。否则，您可以将 #2 和 #3 一起保存在一个库中，并从抽象应用程序库中引用它。

在具体应用程序中，我将创建特定的类 ，引用实用程序和抽象应用程序库(将包含摘要(包括接口)和通用具体内容)。