在经典的ASP中，代码层是最小的。 ASP页面包含HTML和脚本组合。 COM组件包含业务逻辑和DAO基础设施。 ASP页面本身是凌乱的，但一切都在一个地方。
ASP.NET的代码隐藏了代码，没关系。控件允许我们在表示层上更加面向对象。这些东西都不错
这是我的问题我进入的许多项目是企业Web应用程序，但不是那么复杂，所以说10个左右的网页/用户界面，大量的数据库交互等等。这些以前是一块蛋糕要理解。现在我经常会遇到5到10层代码来创建一个相当简单的网页。这些可能包括ASP，代码隐藏，控制类，DTO类，ORM对象，然后还有其他一些刚刚投入到它的地狱。
除了到达数据库的5-10层之外，还有许多创建用于存储普通数据的自定义对象，而不是像例如集合那样使用POCO(普通的老CLR对象)。为了理解这些对象，通常需要追溯包括3个或更多级别的对象和接口的继承性搜索。
这是关键：以前，我看了一个ASP页面，并且说了1到2个小对象，一些SQL查询，这些工作已经完成，并且维护和理解相当简单。
现在，对于同一页面，可能会有50个对象或更多的对象，在自定义命名空间中传播数百个对象。
我问你，代码工匠，这是进步吗？有些人有点笨拙地用自己喜欢的新设计模式玩具吗？有快乐的媒介吗？有没有办法有效地使用设计模式，而不会创建这么多的对象，它变得比旧的程序范例变得更糟的意大利面条代码？
请分享你的想法。
解决方法
此外，许多平庸的开发人员错误地认为，最大限度地提高抽象层次和模式使用，使他们成为更好的开发人员。
最后，许多平庸的开发人员被教导他们应该使用层次，抽象和模式，但没有被教导得很好，不知道如何，何时或为什么。所以他们进入一个项目思考“好吧，我知道我应该在这里有一些层次”，你可以想象出来的是什么。
最终，最佳做法的“最佳实践”是尽可能简单地编码UNTIL，您遇到一个阻碍您前进的真正问题。很多时候，你应该有一个模式或最佳实践在你的工具箱是正确的任务，就像你有一个坚果的正确扳手。最好的做法和模式是工具 – 你不会出现一个锤子，开始摆动，直到你有一个需要捣毁的指甲。同样的软件开发。
