我与许多公司合作，主要是建筑师/主要开发人员，有时直接与开发人员合作。经常出现的一件事是，当建筑师规定应用程序模式时，他们希望每次都能始终遵循它，几乎没有变化的余地。
演示模型/ M-V-VM
一个很好的例子是Presentation Model（M-V-VM）模式。当我想到这种模式时，我认为它是“我们有一个对象模型来表示当前场景的状态和行为，以及一个将它呈现给UI的视图对象”。在我看来，代表国家的事物（模型/视图模型）比规定性指南更具概念性。视图可能使用许多对象来表示此状态，或者它可能使用一个，或者它可能非常简单以至于它不需要，或者它可能共享一个。模式的精神是我们从可视化代码中分离状态管理。
然而，我经常遇到的是字面意思更加模糊的模式。典型项目可能如下所示：
有时，Model对象为空，或者ViewModel只是将属性getter / setter转发给模型对象。有时视图非常简单，额外的对象只会使它变得比它需要的更复杂。
作为架构师/团队负责人，您是否更喜欢开发人员每次都像核对清单一样遵循相同的流程？或者您希望将详细信息留给开发人员？
答案 0 :(得分：3)
每次都将详细信息留给开发人员。一些解决方案可能会变得疯狂＆amp;毛茸茸的，但试图控制细节是一场失败的游戏。开发人员有大脑：告诉他们你想要他们实现的目标，然后再告诉他们具体如何。在定义要遵循的参考架构时，请关注
您作为架构师的工作是确保确定，确定优先级并实现主要的非功能性需求。大多数时候，至少在我与之合作过的那些公司文化中，作为指导和老师比试图为他人做所有的思考更有成效。
答案 1 :(得分：1)
虽然Pontus提出了好点;问题是Presentation实际上是应用程序的结构。因此，如果您想添加新功能，则无法选择。
我自己的CAD / CAM应用在这方面非常严格。通过创建操作模型的新Command对象来添加功能。您需要使用通过使用memento模式开发的对象来保存初始状态，然后保存更改后的状态，以便正确实现undo / redo。
然后，您必须将Command对象放在使用被动视图开发的视图中的一个事件处理结构中。当然，在命令对象中选择算法，支持对象和函数我们的开发人员有相当多的自由裁量权。
如果您正在讨论由公司制作的新应用程序，那么在选择各种模式时通常有充分的理由。在我们公司，我们必须维持数十年的应用，因此设计适应性非常重要。我们不能在开发中使用本月的味道，因为它会在5年，10年，15年后回来并困扰我们。我们的许多应用程序都是使用Passive View设计的，多个层通过定义良好的界面进行连接。当MS决定采用VB6支持VB.NET时，这也很有用。
然后，有时只是经理跟随当月的风味。在这种情况下，您需要尝试教育经理，了解为什么您提出的方法从长远来看会更好地为公司服务。否则，你需要自己教育公司为什么选择它所做的标准。