业务逻辑(BLL)层的组织,长期以来一直是个困惑。打从开始引入ORM后,BLL层不再出现SQL语句和存储过程,感觉思路清晰了不少,现在自己对BLL结构认识大致上定型,一般根据不同方面的业务逻辑,对应不同的命名空间,亦即不同的文件夹,每个文件夹下可能有多个Helper类。对于缓存、日志、邮件等通Helper类,放在Common目录下。

  这是传统的三层架构,如果使用SOA的话,可能多一个服务层,一般来说,项目分层不要超过四层。

  下面说说创建Helper基类的目的,因为各个Helper类,尤其是在Web开发中,都面临一些类似的问题:

  1、如何和数据打交道。有了ORM不能替代我们对性能的思考,比如有时候执行完一个方法,就向数据源提交更改,有时候需要和其它方法一起执行完后再提交更改,并且共享一个数据访问连接。

  2、如何和HttpContext打交道。显然,到处写HttpContext.Current大大增加了系统的耦合性,如果将HttpContext完全排斥在业务逻辑层外,又会UI层和BLL层代码变得复杂。所以封装HttpContext的操作是必要的,同时也对单元测试性提供方便。

  3、如何处理异常和错误。有些异常不影响程序正常处理,如提醒邮件发送失败,要捕获它们,写入系统日志,或给予用户提示。令请求无法正常执行的异常则无需捕获,如数据库连接出错。不同业务逻辑处理,可能会设置一些前提条件,如果因不满足某个条件导致执行失败,也应该有相应的提示。在返回值中表示不同的提示类型,并不足以表示一些复杂多变的场景,比如批量转账,我们应将所有未成功的转账信息集中返回给前端页面。

  所以,个人认为一般的业务处理方法,只需返回成功与否即可,或是void。而将执行中的异常、消息、警告,都在Helper基类的属性中交待。

  一个基本的Helper基类,代码如下:

    /// <summary>/// 所有Helper的基类/// </summary>class BaseHelper<T>{private HttpContext context;/// <summary>/// Web请求上下文/// </summary>public HttpContext Context{get{if (context == null) context = HttpContext.Current;return context;}set { context = value; }}List<T> details;/// <summary>/// 处理细节/// </summary>protected List<T> Details{get{if (details == null) details = new List<T>();return details;}}DBEntities db;/// <summary>/// 涉及数据操作/// </summary>protected DBEntities DB{get{if (db == null) db = new DBEntities();return db;}}/// <summary>/// 是否在方法内保存/// </summary>protected bool AutoSave { get; set; }/// <summary>/// 保存到数据源/// </summary>protected int Save(){if (AutoSave) return DB.SaveChanges();else return 0;}}

另外,还有一些通用的课题,比如缓存同步、权限控制等,也感到了不少局限性,留待以后进一步解决吧。这是最后一个传统的WebForm项目,以后开发方向就以MVC为主了。

转载于:https://www.cnblogs.com/XmNotes/archive/2011/02/19/1958597.html

业务逻辑层的Helper基类相关推荐

  1. 抽象工厂+反射+依赖注入 实现对数据访问层和业务逻辑层的优化

    分层思想的一个核心就是部件化,各个层之间是相互独立的,每一层可以随便抽取换成一个其他语言的版本,但只要与相应的接口吻合就行. 我用的三层架构大致是这样的,基本的三层就不说了,然后分别为业务逻辑层和数据 ...

  2. java业务逻辑层文档,java业务逻辑层类图

    Java 面向对象 16 种设计原则一 类的设计原则 1 ...假如已有的系统中存在以下既有的业务逻辑代码: void...下面的类图将它的 2 个不同职责分成 2 个不同的...... java大作 ...

  3. 系统架构师-基础到企业应用架构-业务逻辑层

    一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开 ...

  4. 系统架构之业务逻辑层

    一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具 体实现方式简单的分为面向过程与面向对象的开 ...

  5. 系统架构师谈企业应用架构之业务逻辑层

    一.上章回顾 上章我们主要讲述了系统设计规范与原则中的具体原则与规范及如何实现满足规范的设计,我们也讲述了通过分离功能点的方式来实现,而在软件开发过程中的具体实现方式简单的分为面向过程与面向对象的开发 ...

  6. 企业应用架构之业务逻辑层的顶层设计与底层思考

    摘要 本文将以架构的方式去分析分层结构中的业务层设计,如何写出来内聚度,高耦合的业务逻辑层,并且如何根据我们的项目功能需要去设计业务层.我们将会通过几种可能的业务层设计模式去分析,分析每种设计模式的优 ...

  7. 细说业务逻辑 -- 丢失的业务逻辑层

    前言 记得几个月前,在一次北京博客园俱乐部的活动上,最后一个环节是话题自由讨论.就是提几个话题,然后大家各自加入感兴趣的话题小组,进行自由讨论.当时金色海洋同学提出了一个话题--"什么是业务 ...

  8. 架构设计-业务逻辑层简述

    业务逻辑层是专门处理软件业务需求的一层,处于数据库之上,服务层之下,完成一些列对Domain Object的CRUD,作为一组微服务提供给服务层来组织在暴露给表现层,如库存检查,用法合法性检查,订单创 ...

  9. petshop详解之五:PetShop之业务逻辑层设计

    五 PetShop之业务逻辑层设计业务逻辑层(Business Logic Layer)无疑是系统架构中体现核心价值的部分.它的关注点主要集中在业务规则的制定.业务流程的实现等与业务需求有关的系统设计 ...

最新文章

  1. 迪杰斯特拉算法——PAT 1003
  2. Centos-6.7下_Oracle 11gR2静默详细安装过程及排错
  3. 有关git clone 下载速度变慢的解决方法
  4. golang response body 多次读取
  5. Log4j、slf4j
  6. sprinigboot(2.2.4)+mysql引入druid的性能监控StateFilter
  7. Golang指针,for循环
  8. Linux 开源 ssh 工具,【原创开源】jssh linux scp ssh 免密登录工具
  9. python 散点图点击链接图片_Python数据可视化——散点图
  10. python pygame字体设置_2015/11/3用Python写游戏,pygame入门(3):字体模块、事件显示和错误处理...
  11. 前端----let关键字、const关键字
  12. 取关几十个优质公众号,是否可惜?
  13. Type 和 class 的区别
  14. 我的世界服务器修改视野,我的世界默认视野是多少度
  15. WP系统一次订阅,终身锁屏同时显示农历和天气
  16. mysql case when 优化_SQL 逻辑优化 case when 转为 union all
  17. 想要绘图效率节省储存空间?CAD内部图块该怎么创建?
  18. thinkphp框架源码交易系统资源网站源码
  19. 计算机专业考研复习方法,2014年东北大学计算机专业——关于考研我个人的复习方法...
  20. Unity | 如何使用webm透明视频

热门文章

  1. 从IBM SCE+落地中国看IDC的转型
  2. poi 技术动态更新 Excel模板内容,动态更新内容
  3. MySQL错误:The user specified as a definer (XXX@XXX) does not exist
  4. Redis学习笔记(3)-XShell连接CentOSMini,并安装Redis
  5. UMeditor上传图片无反应
  6. Linux网络设备驱动概述
  7. Graphics.TranslateTransform设置旋转角度不起作用?
  8. Spring Boot Transactional注解源码阅读笔记(二)
  9. SpringCloud学习成长之路七 高可用配置中心
  10. 物联网时代 公共建筑应该改变些什么