这个公司每个项目用不同的一套开发框架，实在忍不住拿一个出来说说事。

　　

　　我简单说一下，Web是前段、EnglishWeb是英文版、Trip是后台、Common是通用类、Console没用（估计拿来测试的）、Model就是模型了，Business他把业务逻辑、数据处理等等这些放在这里。

　　重点就说Business，这个框架是用spring.net来支撑每一个层之间的联系，而不是我们通常的new一个实例.. 这是我个人觉得最奇葩、最无聊的设计。

　　里面是一坨

　　我解释一下他们平时是怎么开发的，首先DAL做数据处理，然后写接口放在Service下，继承接口实现业务逻辑放在Impl中，前端用spring的方式创建Impl来使用业务逻辑层，而Impl中的所有实例化都是这样的。

　　去spring中配置让它来实例化。先发出我的疑问，

　　疑问1：为什么每个前端使用业务逻辑层全要用spring来创建？这完全没有必要，为何要用spring，注入一个业务逻辑类到页面后台里有任何意义？难不成一个页面能用两套业务逻辑吗。而且是每个都如此！

　　疑问2：Impl是被他们直接当业务逻辑层来使用，BLL层已经失去任何意义了，而且他们这样声明DAL的方式完全就是脱了裤子放屁，连接口都没有的情况下，用spring来创建又有何意义？就算有接口，这里注入的意义何在？

　　还有很多怀疑的地方，都是用spring导致的..就不一一举例了，都差不多一个意思。

　　这个项目让我感觉就是为了用spring而spring，而且分不清分层的意义。

个人观点

　　1、DAL 数据处理层，与数据库直接交互的地方，不应该包含任何业务相关的东西。

　　2、BLL 业务逻辑层，很多人使用都是按表、或则按页面来创建这个层的类，我认为不是这样的，这里应该是梳理好项目中的对象，比如说一个机票系统，机票是一个对象，他可能由很多附属表才能组成机票的整个业务，可是我们只需要一个类，他有很多不同的操作。BLL更像是DAL类的组装厂，而不是1:1。梳理成对象的好处在于，用到机票相关的业务都在这里，不会让同一个逻辑东一个西一个，你写一个他写一个。这也是面向对象编程的意义，如果按表、按页面来创建这一层，那完全是在过程式的编程中没有跳出来。

　　3、页面后台，这里只是获取页面数据、验证数据的地方，不要有太多的业务逻辑了。

什么时候用spring?

　　比如机票我们要算反点了，要用很长一段时间后会换回来，那么这个业务逻辑就有两套，这时用spring来注入是很好的选择。

　　后话：欢迎来喷，探讨才有进步。个人不喜欢教学的东西，讨论才有火花、才有激情，有理有据即可。