我在 GUI 上工作并处理复杂的对象，即对象有其他对象，而这些对象可能有其他对象。
这些对象由各种视图、视图模型、服务、nhibernate 操作（通常几乎同时），你可以命名它 - 做一些简单的事情，比如保存/更新/删除/验证等。
在大多数情况下，像 NotifyPropertyChanged 这样的东西就足够了，但并非总是如此。有时我决定调用 EventAggregator 但当对象图很大时 ，尤其是此类对象的集合 - 它变得如此混乱，我一直在失去目标，不确定特定对象的确切状态是什么，并且通常不确定它是否仍然是同一个对象或一些它的松散副本；
所以我的问题是管理对象状态和避免“状态爆炸”的最佳方法/方法是什么？
通过引入额外的结构来简化。最好的方法是给应用程序更多的结构。将应用程序分成更小的内部生活部分，您可以很好地监督和控制这些部分。让这些部分隐藏在外观/适配器类型之后，这些类型仅公开系统该部分的简化视图。只要有必要就递归地重复。使用正式模型来定义结构和相互通信规则，例如 UML 2.0 分层状态机通常很合适......我知道，这只是一个通用工程 bla-bla，但它可以帮助......
我建议您注意 和 的一本书敏捷原则、模式和实践在 C#中Robert C. Martin，Micah Martin有很多很好的例子展示了如何设计一个系统UML，以及其他类似的方法。具体来说，它展示了为什么你应该重构你的代码，可以存储在抽象类中，什么不是。你可以立即看到一个咖啡机的例子Mark IV，他开发了一个真正独立的界面。
根据我的感受，MVVM 的主要原则是数据与其表示的独立性。我喜欢尝试制作单独的模块，这些模块实现单独的逻辑，而不知道数据。比如SQL模块、SMTP模块等，简单的包含了ConnectToDb()orSendEmail()之类的方法，主要逻辑在ViewModel，她将这些Work-modules与数据模型结合起来。
在设计系统之前绘制图表很有用，但也不要参与其中。最重要的是看到论文中的主要部分，并且其他人会像你所知（或架构师）一样理解它。