架构是一种妥协

        车辆调度系统陆续写了半年时间了，中间经历老人故去，儿子降生，一波三折。最近才静下心来写了一周时间，由于是在前一个版本上迭代开发的，整体速度还是很快的。而且在和尚兄的指导下，系统使用的技术有了很多进步。比如首次使用了Asp.net的窗体验证机制，EF的生命周期管理等东西。并且对界面做了一些改进，整体已经非常成熟了。从实现功能的角度来说是完全没有问题的。
         我使用了三层架构来重新搭建这个系统，看上去好像没有什么问题。但是写着写着，问题就出来了。三层中的业务层，只是简单的调用了DAL层中的一些方法，做了一些简单的判断。可以理解为DAL层的一个门面模式。由于都是一个人在写，越来越觉得这东西是脱裤子放屁多此一举。
         什么是业务层？我说不清楚，越来越觉得这个东西弊病太多。
        之所以使用BLL，更多的是一种技术上的不自信，一味地想向标准靠拢，没有考虑实际情况。
        很多人号称的三层架构，其实也和我一样，都是调用了DAL中CRUD方法。真的做到解耦合了吗？未必。
        我们的核心业务变化不大，和互联网场景不一样，是一套典型的CRUD集中的业务。加上内网良好的网络环境和高效的服务器支持，所以整个业务是偏向前端的，就是说网页要做的漂亮，操作起来要顺手。网页端的变化性比较大。而后端核心业务的变化其实并不大。
        为什么一定要使用三层呢？从UI层直接访问DAL层不也可以吗？但是有人说了，这样代码不够简洁，臃肿。
        事实上，很多小型系统都没有使用所谓的三层架构。
       抛开技术不谈，三层架构实际上更多的是分担复杂性的一种方法，让好几拨人来分别干不同的活儿。而目前这种场景下，我一个人干所有的活儿，可扩展性并不那么重要。更多的是简洁快速的编写出稳定可运行的代码。
        所有的架构都是一种选择，要根据具体的环境来做决定，不可拘泥，切记切记！