我的解决方案/项目结构是这样的
- 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 ,依此类推...
我的模块只是视图,模型和ViewModel。但是,例如,当我使用Caliburn Micro时,我必须继承框架中定义的基类。或在我的视图中使用附加属性。
我觉得这很奇怪。所以我的问题实际上是:这不是某种反模式吗? ViewModels不应该照顾基础设施,对吧?
答案 0 :(得分:0)
在MVC / MVVM框架中,其思想是确保在V,M和C(VM)层之间分离代码的“类型”。
请勿执行的示例
例如,有一家公司希望使用ColdFusion将以VS C#编码的应用程序转换为浏览器版本(网站),以便多个用户无需安装任何内容即可在线使用它。但是,我们发现在他们的视图层中,他们的业务逻辑中有很大一部分,他们不使用接口,而是使用纯继承,繁琐的耦合以及其他使代码纠缠的事情。
如果他们没有这些问题,我们可以将大多数内容移动到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
个人观点
框架很棒。它们包含有用的库,为程序员提供了遵循的标准,并且通常带有may示例。但是,您可能会依赖该框架。
例如,iOS框架和Android框架的功能有所不同,并且使用的语言也不同。除非您使用的是将代码转换为任何一个框架的解决方案,否则您都会陷入困境。
就我而言,在过去,我必须为某个应用程序维护iOS和Android。我的方法是让我的业务逻辑和模型在与框架进行交互时使用接口和适配器。
无论使用哪种语言(Java或iOS),业务逻辑都是相同的=减少了工作量。
使用接口使它变得更容易。我使自己成为语言转换器,并且仅在业务逻辑和接口上使用它。由于业务逻辑和接口不使用框架和语言所特有的对象或变量,因此转换很容易。
适配器确保业务逻辑与框架之间的通信相同。业务逻辑不在乎该框架是Android并使用CounterDownTimer还是在iOS中并使用NSTimer。业务逻辑只知道连接到TimerAdapter时使用的接口ITimer。