Xamarin 架构项目或命名空间答案

【问题标题】：Xamarin Architecture Projects or NamespacesXamarin 架构项目或命名空间
【发布时间】：2016-09-01 14:49:33
【问题描述】：

我正在使用 Xamarin 开发适用于 iOS、Android 和 Windows 手机的应用程序，但我对架构有疑问。从他们的网站：

从他们提供的示例解决方案中：

link to git source

他们将业务层、数据访问层和数据层放在同一个项目中。

但在此之后，当他们解释架构时：

封装：[...] 这意味着 UI 代码（例如）应该只负责显示屏幕和接受用户输入；并且从不直接与数据库交互。 [...]

和：

[...]将代码分层使应用程序更易于理解、测试和维护。建议每一层中的代码在物理上是独立的（在目录中，甚至对于非常大的应用程序来说是独立的项目）以及在逻辑上是独立的（使用命名空间）。[...] （强调我的）

如果他们在不同的项目上不是更好吗？我的意思是，如果都在同一个项目中，并且我在UI层引用了这个项目，那么我可以直接访问业务层和数据层，我不知道这是否正确。

问题是：

可以接受（并且接受），用目录分隔层吗？

用目录和命名空间或项目分隔层更好（或最被接受）？

【问题讨论】：

到目前为止的所有答案都帮助我看到在项目中分离层并不总是必要的。可惜只能接受一个。

标签： xamarin architecture

【解决方案1】：

这个问题没有正确答案。关注点分离通常被认为是一个好的设计目标；但是，您采取的程度和/或实施的具体方式因项目而异。对于 Xamarin 提供的许多示例项目，它们不足以证明将数据/域/等分解为单独的项目是合理的。

【讨论】：

我想这回答了第一个问题。根据项目的特点，以任何形式分离层都是可以接受的。问题在于了解项目必须具备哪些特征，以一种或另一种方式进行分离。

【解决方案2】：

如果他们在不同的项目上不是更好吗？我的意思是，如果都在同一个项目中，我在 UI 中引用了这个项目层，然后我可以访问业务层和数据层直接说，不知道对不对。

....

可以接受（并且接受），用目录？

最好（或大多数人接受）将层与目录分开和命名空间，还是与项目？

关于你的第一个问题：没关系。假设您将每一层拆分为一个不同的项目（这意味着您为每一层获得一个程序集）。正如您所指出的，您仍然可以从更高的层访问那些较低层中的代码。应用程序分层的原则只是说一层中的代码不能引用更高层中的代码 - 它确实不阻止您访问堆栈中“更深”的代码。阻止这种情况的唯一边界是“层级”边界——它更加正式（而且跨越成本更高）。

关于第二个问题：当然，如果你愿意，你可以这样做。但这不是强制性的。您当然可以拥有分层架构，而无需将每一层拆分为子文件夹/命名空间。有时它甚至可能会妨碍您。对于某些设计理念（例如某些形式的 DDD），最好使用命名空间来对垂直特征进行分组，而每一层的各种类都驻留在同一个特征命名空间中（通常使用类命名约定来标识层） .

关于第三个问题：除非您有充分的理由，否则我不会将层分成项目。 “好的理由”包括：在应用程序之间共享代码、黑盒风格的单元测试，或防止开发团队在大型系统中发生冲突，其中开发团队拥有整个系统的一部分，并且代码需要以非常快的方式合并到更大的主线中。带有正式验收检查点的受控流程。

我当然不会仅仅为了分层而将代码拆分为多个项目。每个额外的项目都会增加构建过程的开销。并且在某些时候，IDE 会开始阻塞它（尽管通常直到您在解决方案中获得超过 30 个左右的项目）。

实际上，绝大多数移动应用程序的规模或复杂性都不足以证明对这个主题进行过多思考的合理性。如果您的项目足够大以至于您正在考虑将其沿层边界拆分，那么可能是时候退后一步并重新考虑范围了。

【讨论】：

【解决方案3】：

正如 Jason 正确指出的那样，与大多数设计决策一样，这取决于。

只需考虑几件事：

按项目拆分

清晰的关注点分离
更好的代码重用
允许强命名
更清晰的依赖管理（与命名空间相比，意外引用项目的可能性更小）
许可 - 如果您希望所有开发人员都在模型/视图模型上工作，但只有几个 Xamarin（或其他）许可
多个团队 - 如果项目足够大，您可能会有团队在每一层上工作。
对于大型项目，拆分将允许您将每一层都分配到内部存储库（例如 nuget）以供其他团队使用
允许对每一层进行独立构建/测试

按文件夹拆分

更简单的小型应用程序/POC/原型
性能 - some discussion here
项目更少，IDE 更快，因此开发速度更快
项目更少，构建速度更快

【讨论】：