我的解决方案/项目结构是这样的
- MyApp.App
- MyApp.Domain // everything that's shared between projects
// in one assembly for simplicity
- MyApp.Modules.ModuleA
- MyApp.Modules.ModuleB
- MyApp.Modules.ModuleC
MyApp.App 可以访问框架并连接 shell 等等...
我的模块只是视图、模型和视图模型。但是当我使用 Caliburn Micro 时——例如——我必须从框架中定义的基类继承。或者在我的视图中使用附加属性。
这对我来说似乎很奇怪。所以我的问题实际上是：这不是某种反模式吗？ ViewModel 不应该负责基础设施，对吧？
【问题讨论】：
标签： c# mvvm caliburn.micro
在 MVC/MVVM 框架中，其想法是确保您在 V、M 和 C (VM) 层之间分离代码的“类型”。
不该做的事示例
例如，有一家公司希望将使用 VS C# 编码的应用程序转换为带有 ColdFusion 的浏览器版本（网站），以便多个用户可以在线使用它而无需安装任何东西。但是我们发现他们的视图层有很大一部分业务逻辑，他们没有使用接口，而是纯继承，耦合度高，以及其他会使代码纠缠的东西。
如果他们没有这些问题，我们可以将大部分内容移到 dll 中，然后只专注于 Coldfusion 中的视图部分，其余部分使用这些 dll。
有用的参考资料
阅读 Robert C. Martin 所著的 Clean Code 一书。它对编码有很好的论点和想法。
了解 S.O.L.I.D. 背后的理念：https://en.wikipedia.org/wiki/SOLID
查看测试驱动开发：https://en.wikipedia.org/wiki/Test-driven_development
个人意见
框架很棒。它们包含有用的库，强加了程序员遵循的标准，并且通常带有可能的示例；但是，您可能会依赖该框架。
例如，iOS 框架和 Android 框架做事不同，它们使用不同的语言。除非您使用将代码转换为任一框架的解决方案，否则您将陷入困境。
就我而言，在过去，我必须为某个应用程序维护 iOS 和 Android。我的方法是让我的业务逻辑和模型在与框架交互时使用接口和适配器。
无论使用哪种语言（Java 或 iOS），业务逻辑都是相同的 = 工作量更少。
接口的使用使它变得更容易。我自己做了一个语言转换器，只在业务逻辑和接口上使用它。由于业务逻辑和接口没有使用框架和语言特有的对象或变量，因此很容易进行转换。
适配器确保业务逻辑和框架之间的通信是相同的。业务逻辑并不关心框架是 Android 并使用 CounterDownTimer 还是 iOS 并使用 NSTimer。业务逻辑只知道连接 TimerAdapter 时使用的接口 ITimer。
【讨论】：