0

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

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

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

  6. GameController, TrackView, CarView, CarProxy,TrackProxy等等。模型<->视图共享的数据是CarVo, TrackVo, TrackListVo,CarListVo等等

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

4

1 回答 1

1

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

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

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

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

于 2012-12-03T15:22:57.833 回答