我正在为之工作的公司目前正在使用存储过程(在Mssql服务器后端)作为其业务逻辑层.实际的业务逻辑DLL只调用sProcs并基本上管理UI(事件,数据绑定等)
我觉得设置有问题,虽然我不确定如何向同事解释.顺便说一句,系统工作.
我工作场所的“最佳实践”是错误的吗？或者我只是想过这个？
解决方法
GaiusSensei – 只要业务领域能够处理业务实践中的地震变化,就可以以这种方式工作.我认为SP和BLL dll之间的争论仍然存在,毫无疑问,双方在这个问题上会有很多.但是,根据我自己在过去10年中对一系列项目的经验,以下是我对BLL dll方法的支持：
> BLL中包含的逻辑可以
“不可知”的存储介质和
因此更灵活
(这种情况发生的频率是多少
值得商榷)
>对业务进行更细致的控制
权限ACROSS的范围
依赖于的应用程序
数据存储.我的意思是核心
表必须完整的表
保持在特定的水平
它在企业内部使用
有问题的申请.
> BLL逻辑可以封装在自己中
包含可以重复使用的类
在其他业务领域和/或
项目.班级甚至可以
写作密封的类或
可扩展性取决于您的目标
‘听众’
>单元测试 – 这个(在我的
经验)如果使用黑色艺术
SP内部.在java / c#等下,这个
是一个标准,有些人会说
现在强制执业.
>可维护性.保持良好
BLL dll中组织的接口
方案,你可以轻松实现
支持开发人员扩展您的
课程没有破坏现有的
逻辑
>便携性.你的BLL(取决于
语言实现)可以
托管在各种平台上.
同样,注射了
数据存储的实现可以
字面上可以是xml中的任何内容
文件到MysqL,mssql postgres等,
等等
>标准化.数据架构师
可以准确定义每个数据的方式
元素应该取自
数据库以及每个项目应该如何
保存(因为这将更好地位于DAL dll中).因此,进入的成本
新开发商以及经验丰富的项目都很多
降低.
这个列表继续,但是,这些是我采用BLL方法的头顶PROS.
在这一个看起来很多旋转:)
吉姆
[编辑] – 我还要补充一点,这个BLL不应该发出任何UI信息,除了(如你所说)传达事件等每个UI层(与目标设备相关 – 浏览器/移动设备/工厂)应该参考BLL并用数据自己做’thang’.我进一步补充说,BLL下面将是你的DAL层.可以将此层视为基础数据存储区的1-1引用.
