您的位置:知识库 » 软件设计

好菜都得花功夫做

作者: 夏天可是个好季节  来源: 博客园  发布时间: 2012-12-07 21:50  阅读: 4010 次  推荐: 16   原文链接   [收藏]  

  平常下班时间太紧张,炒菜从洗菜到上桌也就十几分钟,味道自然就一般般了。到了周末,终于能花点时间做“大餐”了。这“大餐”之所以好吃,我觉得主要原因是食材入味深,火候匀,有时还需要经过多种烹调方法。例如这红烧猪蹄,就先得把猪蹄剁块儿;锅内烧好了开水,把猪蹄放进去焯。焯过的猪蹄要及时放在凉水中泡十分钟,这样做出来的猪蹄虽然软但又有“筋道”的口感。然后炒锅里放一点点油,将冰糖熬化,放入猪蹄上色。将上色的猪蹄放入高压锅,放入酱油,料酒,葱姜蒜大料。压30分钟。而后将猪蹄连汤取出,放入炒锅,大火收汁装盘。(如果喜欢清甜的味道还可以在高压锅入锅的时候放一颗丁香)

  我这是不是发错地方了呢,大家说我是干嘛的。实际上我是实打实在代码里劳作的老农(论年头不少了,还好年纪尚轻)。工作中的一个项目,已经进入了第三个年头,发布了两次版本,积累了很多教训。但是最近这段时间却非常没有干劲儿。原来我以为我决不会沦为拼命追逐技术的变化最后筋疲力尽退出历史舞台的人,但是现在却发现这种趋势越来越明显。这个月终于看到了Visual Studio 2012 RC的发布,但是却没有足够的动力去下载安装争当“小白鼠”。

  但是我终究还是下载了,果然我看到了很多很多的改进,不论从界面响应还是Framework的变化。例如:MVC已经升级到了4,WCF 的 REST 已经成为了 MVC Web API,Metro Style 支持,EF 的升级,等等……各类博客又出现了MVC4+EF组合,Web API构造REST服务,等等的各类文章。我没精打采的看着,突然觉得,这种思路进入的是一种恶性循环状态。以 Web 应用为例,从 ASP.NET -> ASP.NET MVC,这实际上仅仅是更有利于界面与逻辑分离,但是这进步犯得着你重新书写你的后台吗?当然不用,因为MVC对你的后台逻辑没有影响。我们的程序之所以能够去卖,能够获得成功或者失败,不在于你使用的是 ASP.NET MVC 还是 Web Form,或者是其他什么东西,而是你的业务实现,你的用户体验。这才是程序的价值。如果仅仅是由于架构的变化就思考业务是不是要重新来过,未免舍本趋末。实际上,好多项目并没有一个相对稳定的Code Base,自保尚且不及,更别论进化了。

  另一个问题是——生活永远不像博客中举的例子那样简单。ASP.NET Form Authentication,是干什么的?ASP.NET Role Based Authorization 能灵活配置满足你应用的 Access Control 需求吗?很遗憾,Authorization 实际上是一个很复杂的问题,但是我们不能因为这个,就觉得需求过于复杂,或者 Form Authentication / Authorization 太弱。另一个问题集中体现在了 Entity Framework 上。我看到了不计其数的 Repository 写成了 Database 的 Gateway(我当然不会笑话别人,我自己就写成了这样)。我也怨 Entity Framework 太弱,怎么处理外键?怎么处理Nested Object?为什么Enum映射这种看似“非常简单”的功能就是迟迟出不来。但是我为什么没有想过,Repository 是谁的 Repository?到底是 Data Set 还是 Domain Model。当然,应该是 Domain Model。Domain Model 和数据库的表的对应关系难道就是直接“拖动”这么简单吗?当然不是,那么这种复杂的映射就是你智慧的结晶,是你对业务的理解。EF很好,但是这并不是说你一定要使用EF的ObjectContext来实现 Unit Of Work,实现 Object Mapping。也不是说你仅仅靠轻轻的拖动“鼠标”就可以搞定一切领域模型的映射。问题都处在我们自己的懒惰和浮躁上,而不是 EF 太弱。

  我错就错在了将精力集中在了芝麻而不是西瓜上,这么多的 Framework,如此多的 DSL,让原本一些复杂的功能得到了简化。但是这些 Framework 并不想让你把精力集中在他们身上,而希望解放你的生产力,让你把精力集中在具体的业务上。去用心的设计你的业务,在业务上尽情的展现你对各种方法论的理解。悲哀的是,我们并没有领他们的情,我们把聚光灯全都用在了他们身上,让真正的业务逻辑穿的破破烂烂在角落里哭泣。

  就拿 Authorization 来说吧,假设一个系统要求一种“具体”的 Role Based Access Control,我如何实现这个需求。别误会,这不是 ASP.NET Authorization 能搞定的。我明白相关的理论吗?我能够知道认证需要那些要素吗?这些要素将如何从 Base 上影响 Domain Model 的设计?实际上,每一个系统都需要的功能,往往是最具技术含量的。放下浮华,我还是回到业务逻辑上来吧,Framework就像是时下流行的网络用语,过几年也许没人记得他们。但是 Code Base 将永远发光,养活你和你的家,甚至养活大家。

  就像炒菜,好菜,是要耗功夫的,没有什么捷径。

16
0

软件设计热门文章

    软件设计最新文章

      最新新闻

        热门新闻