Xamarin架构项目或命名空间

Question

我正在使用Xamarin为iOS，Android和Windows手机开发应用程序，我对这个架构有疑问。来自他们的网站：

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

link to git source

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

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

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

和

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

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

问题是：

将图层与目录分开是否可以接受（并接受）？

将图层与名称空间或项目分开是否更好（或最常被接受）？

Answer 1

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

Answer 2

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

只需要考虑几点：

按项目拆分

• 明确分离关注点
• 更好的代码重用
• 允许强有力的命名
• 更清晰的依赖关系管理（不太可能意外地引用项目而非命名空间）
• 许可 - 如果您希望所有开发人员使用模型/ viewmodel但只有几个Xamarin（或其他）许可证
• 多个团队 - 如果项目足够大，您可能有团队在每个层上工作。
• 对于大型项目，分割将允许您将每个图层用于内部回购（例如nuget）以供其他团队使用
• 允许每层的独立构建/测试

按文件夹拆分

• 对于较小的应用程序/ POC /原型更简单
• 效果 - some discussion here
• 减少项目，加快IDE速度，从而加快开发速度
• 减少项目，加快构建速度

Answer 3

  

如果他们在单独的项目上会不会更好？我的意思是，如果   所有这些都在同一个项目中，我在UI中引用了这个项目   层，然后我可以访问业务层和数据层   直接，我不知道这是否正确。

     

...

     

将图层分开是可以接受的（并且已被接受）   目录？

     

将图层与目录分开会更好（或最常被接受）   和命名空间，或与项目？

关于你的第一个问题：没关系。假设您将每个图层拆分为一个不同的项目（这意味着您为每个图层分配了一个程序集）。如您所述，您仍然可以从较高层中访问较低层中的代码。应用程序分层的原则只是说一层中的代码不能引用更高层中的代码 - 它不阻止您访问堆栈中“更深”的代码。防止这种情况的唯一边界是“层级”边界 - 这种边界更为正式（跨越更昂贵）。

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

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

我肯定不会仅仅为了分层而将代码分成更多的项目。每个附加项目都会增加构建过程的开销。并且在某些时候，IDE将开始扼杀它（尽管通常直到你在解决方案中获得大约30个项目）。

实际上，绝大多数移动应用程序都不会很大或太复杂，无法在这个主题上多考虑。如果您的项目足够大，以至于您正在考虑沿着层边界将其拆分，那么可能是时候退一步并重新考虑范围了。