这个公司每个项目用不同的一套开发框架,实在忍不住拿一个出来说说事。
我简单说一下,Web是前段、EnglishWeb是英文版、Trip是后台、Common是通用类、Console没用(估计拿来测试的)、Model就是模型了,Business他把业务逻辑、数据处理等等这些放在这里。
重点就说Business,这个框架是用spring.net来支撑每一个层之间的联系,而不是我们通常的new一个实例.. 这是我个人觉得最奇葩、最无聊的设计。
里面是一坨
这边是Service的东西
我解释一下他们平时是怎么开发的,首先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来注入是很好的选择。
后话:欢迎来喷,探讨才有进步。个人不喜欢教学的东西,讨论才有火花、才有激情,有理有据即可。