ASP.NET - 如何在不过度工程的情况下有效地使用设计模式!

自从ASP.NET问世以来,我一直很欣赏人们对困境的看法.

在传统的ASP中,代码层是最小的.ASP页面包含HTML和脚本组合.COM组件包含业务逻辑和DAO基础设施.ASP页面本身很混乱,但一切都在一个地方.

ASP.NET的代码隐藏了代码,这很好.控件允许我们在表示层上更加面向对象.这些都很好.

这是我的问题.我进入的许多项目都是企业Web应用程序,但并非所有复杂的项目,例如10个左右的网页/用户界面,大量的数据库交互等等.这些过去常常是一块蛋糕.现在我经常会遇到5到10层代码来创建一个相当简单的网页.这些可能包括ASP,代码隐藏,控制类,DTO类,ORM对象,然后还有一些其他人刚刚投入其中.

除了要访问数据库的5-10层之外,还有许多用于存储普通数据的自定义对象,而不是使用POCO(普通的旧CLR对象),例如集合.要理解这些对象,通常需要追溯包含3个或更多级别对象和接口的继承层次结构.

这是关键所在:以前,我查看了1个ASP页面并说了1或2个小对象,一些SQL查询,这些完成了工作并且维护和理解相当简单.

现在,对于同一页面,可能有50个或更多对象,在自定义命名空间中传播数百个对象.

我问你,代码工匠,这是进步吗？是否有些人对他们有趣的新设计模式玩具有点过分了？有幸福的媒介吗？ 有没有办法有效地使用设计模式而不创建如此多的对象,以至于它变得比旧的程序范式更糟糕的意大利面条代码？

请分享你的想法.

撇开组织需要这些抽象级别的可能性(不太可能,但它确实发生),开发人员(特别是在非敏捷的企业/企业环境中)添加太多抽象层是很常见的.它发生在经典的ASP上,.NET让它变得更容易.我们这个行业的大多数人都有过于复杂化的自然倾向,需要纪律和积极的思维来克服这一点.

此外,许多平庸的开发人员错误地认为最大化抽象层和模式使用使他们成为更好的开发人员.

最后,许多平庸的开发人员被教导他们应该使用层次,抽象和模式,但是没有足够好地教授知道如何,何时或为什么.所以他们进入一个项目思考"嗯,我知道我应该在这里有一些层......"你可以想象出来的是什么.

最终,最佳实践的"最佳实践"是尽可能简单地编码,直到遇到阻碍您前进的真正问题.很多时候,您应该在工具箱中使用适合该任务的模式或最佳实践,就像您使用正确的螺母扳手一样.最佳实践和模式是工具 - 你不会拿出锤子并开始摆动,直到你有一个需要砸的钉子.与软件开发同样如此.

有些人是建筑宇航员,他们会坚持认为这些层都是必要的,除非你包含它们,否则设计绝对是垃圾.

另一方面,人们将这一切推到一边,只是将代码全部放在一起:它很简单,对,为什么不在代码隐藏中填充到列表框控件的SQL查询呢？

您已经确定了宇航员版本的问题,执行简单任务就太复杂了.

第二种方法的问题在于,虽然它适用于小型,小型应用程序,但这些相同的应用程序有成长为大型应用程序的趋势,然后它们都会崩溃.您花费大量时间反复修复相同的错误,因为相同的查询或代码片段已根据需要进行复制/粘贴,并稍作修改,并在任何地方传播.

当然,有一个中间立场.根据你问的是谁,究竟是哪个谎言会有所不同......但它就在那里.

建立一个理智的业务层是实现目标的一个很好的一步.这应该是一个层,它提供了系统中对象的最简单视图,并且不包含面向公众的数据库相关内容(除了可能告诉业务层如何到达数据库的Connection对象).这将您的所有逻辑合并到一个位置,因此项目的ASP部分只是将抽象的"User.LoadAll()"方法连接到显示用户列表的表.ASP应用程序应该没有任何线索,如果它是从数据库,Web服务,或只是一堆组成的东西读取..它只是与业务层进行对话.

在业务层下,你可以直接查询,你可以使用ORM,你可以建立一个更深层次的数据访问层来完成这些事情.好处是这个决定完全由业务层包含(你可以在以后更改它) ,如果需要,不影响业务层的公共API).

现在,任何与用户打交道的查询都包含在User对象中..如果您对加载权限的方式有疑问,可以在一个地方修复它.

我刚才进行了一次迁移,就像我上面描述的那样(ASP代码隐藏的SQL,一个独特的表示 - 业务 - 数据源(ORM)层),它很棒.虽然它确实增加了一些层次来获取实际信息,但是一旦业务方法起作用,其余代码就可以工作.修复错误很简单,并在任何地方修复它.接近结束时,很快就会出现这样的情况:当您需要获取用户可以运行的报告列表时,有人已经为此编写了一个业务方法(User.GetReports()),之前,您可能永远不会找到它,如果它已经完成 - 如果你很幸运,它被写成一个函数而不仅仅是内联代码.