也许我的问题与这个类似: 你使用设计模式吗？
我编写的程序主要是使用 Windows Forms 和 ASP.NET，代码量大约在50-75 K行左右。这些程序需要进行GUI设计和布局，包括各种图形和图形处理。
我认为自己很擅长面向对象编程（OOP），并且擅长平衡OOP和传统的过程式方法以创建易于维护的代码。
问题出现在我考虑设计模式时。链接的线程有一个有趣的评论，即可能使用设计模式，但没有刻意这样做。当我想有意识地使用设计模式（在程序设计中），感觉就像我正在超越所需的范围，我在“架构宇航员”的领域中，所以我回到传统的方法，一切都正常进行。
以MVC模式为例。如果我想使用 Windows Forms 或 ASP.NET (Visual Studio 2005) 实现此模式，那么我必须编写一个“框架”，而编写框架似乎比应用程序的规模还要麻烦。
也许我的应用程序太小了，无法证明使用某些模式的必要性。也许我只是不够了解这些模式或需要更深入地研究它们。
是否有其他人有过这种“架构宇航员”的感觉？
如何有意识地使用设计模式而不过度使用呢？
'如何有意识地使用设计模式而不过度使用？'
很简单。
不要将MVC框架的开发与模式混为一谈。
认识到你所做的每一件事情都曾被其他人（或者你自己）做过。
当你重复某个东西——任何东西——时，你正在遵循一种模式。
当你重复设计某个东西——无论多么小——时，你正在遵循一种设计模式。
当你注意到自己在重复某个东西时，给那个东西起一个名字。看，你已经发现并命名了你的第一个设计模式。无论大小。
当你命名了一个设计模式，你可以考虑何时使用它，为什么使用它，它解决了什么问题以及使用它的后果是什么。无论大小。
所有涉及“重复设计元素”的学习都是设计模式。无论大小。
每一个循环，每一个if语句，每一个对话框，每一个文件打开，这些都是设计模式。
大多数是语言的一部分，并且具有明显的语言特定名称。“IF”，“OPEN”等等。
一些设计模式比单个语句更大，但比整个MVC框架小。这些才是有趣的。学习它们。购买一本书。阅读它。MVC不会出现在大多数设计模式书籍中，因为——嗯——它太复杂，太难应用了。
不要从MVC开始。从其他任何东西开始。
“架构宇航员”是那些花费大量时间讨论设计但实际上并没有任何实际行动的人。
我喜欢《重构与模式》这本书中提出的设计模式方法。在这里，模式不是我们预先投入的，而是仅在代码复杂性妨碍了开发后，用来减少代码复杂性的东西。因为这种方法需要先有可用的代码，并选择基于使代码更易于满足特定需求的重构，所以非常注重结果。
几乎任何一个适当的设计模式，应用时都应该能够简化问题。如果你让事情变得更加复杂，那么你可能正在朝着错误的方向解决你的特定问题。
MVC本身并不要求您编写任何框架，它只是意味着您将视图、控制器和模型代码分开。即使是编写简单的移动应用程序，我也会使用MVC（或 MVP），因为我发现控制分离在编写测试时非常有利（更不用说在更改UI时了）。
我猜想您现在做的单元测试或集成测试不多，所以这种分离对于提高代码质量和可读性并不是那么明显。
我强烈建议您阅读Fowler关于UI架构的覆盖范围。
不要忘记沟通 - 众所周知的设计模式可以用几个词语来传达复杂的内容。当你说“使用观察者模式进行通知传递”，每个人都知道你的意思。
设计模式只是针对一般问题的抽象解决方案。如果人们了解这些模式，那么他们更有可能应用已知的解决方案，更快地解决问题，而不是坐在那里思考：“哎呀，我该怎么让它工作？”
关于框架：如果你曾经在一个超过一个人的团队中工作过（根据你的项目规模来看，似乎并没有），框架可以帮助每个人以相同的方式完成任务，这在团队合作中非常重要，可以提高可维护性和快速将新成员融入团队。
简单的问题通常需要简单的解决方案，尽管一些困难的问题非常简单。而复杂的问题则可以通过有组织的方式或“肮脏”的代码来解决。许多人试图组织软件设计，并出现了一些“模式”并得到名称。
我认为模式是有用的词汇，当你向他人传达你的设计意图时，但这并不是你强加于设计中的东西。当您根据需要使您的代码解耦时，可以根据需要应用模式。例如，在您发现自己创建非常复杂的构造函数时，放入生成器模式。
从我的角度来看，将数据层和 UI 层从业务逻辑中解耦，就像是一个很好的设计一样。再次强调，低耦合、 DRY 以及可维护的代码应该是目标，而不是模式。
对我来说，这取决于：
在小型应用程序中，除非它们在扩展或维护应用程序的范围内具有很高的回报率，否则我不太可能使用任何不自然的设计模式。
