我曾经开始一个MVVM / WPF项目，该项目最终得以构建和部署，为此，我研究了很多Caliburn.Micro MVVM框架。事实是：我最终没有为此使用Caliburn.Micro，最终自己实现了一些MVVM概念（特别是ViewModelBaseand RoutedCommand类）。
现在，我按照相同的原则被分配到一个更大的项目：可以说，“单用户富客户端脱机桌面应用程序”，因此我决定使用Caliburn.Micro。这就是我的“问题”开始的地方。
我已经读过一篇著名的博客文章，其标题为“如果您正在使用MVVM，那么您需要一个框架”，即：
“在没有框架的情况下尝试进行诸如MVVM之类的工作是一项巨大的工作。大量重复的代码，重新发明轮子，并训练人们以不同的方式思考。
至少在框架下，您可以避免重复的代码，并希望不必重新发明轮子，从而使您可以专注于对人员进行再培训。再培训部分通常是不可避免的，但是框架提供了管道代码和结构，使过程更容易。”
我会同意一读，但是我在Caliburn.Micro（CM）实际应用中的实际经验是无知和迷失方向。也就是说，该框架根本没有使过程变得更容易，相反。阅读由罗布·艾森伯格相当（太）非正式文档中提供不断重复的例子，从旋绕提供的样品试图推断使用模式，他们完全间接的类和接口的关系，这里的东西似乎被设计为工作基础上除非您是一个经验丰富的天才，否则副作用似乎是人类不可能做到的（对不起，这只蚂蚁很抱歉，但我想您知道我的意思）。
更不用说任何上述琐碎的场景似乎都涉及IoC容器，这是我从未使用过的东西，并且似乎解决了我什至没有的问题。我不想花更多的项目时间来学习这些东西，而不必考虑我的问题和应用程序领域。我只想要一个香蕉，但CM给了我一个拿着一篮香蕉的大猩猩（IoC）。
现在，我正在考虑回到我自己家乡的MVVM框架-仅由我实际上要实现的少数特定于MVVM的类组成-我想至少给CM一个机会，以防万一我在这里丢失了一些东西，或者只是出于纯粹的经验和愚昧无知地“错误地”做事。所以问题是：
人们普遍认为“框架使事情变得更加轻松自然”，但是如果碰巧相反，这是否意味着我不应该使用该框架，或者我试图以错误的方式学习它？有没有一个线索，我什至不应该使用框架？还是有一些“正确”的方法来弄清楚如何将CM用于简单的MVVM开发？
RelayCommand实现（因为它按照约定直接“绑定”到方法，而不是绑定到ICommand属性）。
RelayCommand如果Caliburn Micro 使用的库不适合您，我看不出您无法使用其他库中的任何原因。
EventAggregator进行消息传递，NotificationObject使用ViewModelBase和使用MVVM LightRelayCommand进行命令。重要的是要确定框架将为您解决哪些问题，并仅使用这些解决方案。不要觉得您被迫使用整个框架库。