后端程序编码规范

JerryXia 发表于 , 阅读 (3,273)

这既是一个开发规范,本规范不是一成不变的必须严格遵守的条文,特殊情况下要灵活运用,可以做一定程度的变通。但是,请大家在实际开发过程中尽量遵守本规范,以利于协作。同时该规范还会指导Code Review,和设计评审等行为。

【命名规范】

1.1、命名总规则

  • 所有名称的字符范围为:A-Z, a-z, 0-9 和_(下划线)。不建议使用其他字符作为名称。
  • 采用英文单词或英文短语(包括缩写)作为名称,不使用无意义的字符或汉语拼音。
  • 名称应该清晰明了,能够准确表达事物的含义,最好可读,遵循“见名知意”的原则。
  • 提倡英文命名,切忌英文和拼音混用。

1.2、类库Namespace命名

类库分成三个层次,分别是.Net框架、公司基础公共类库、项目级类库。公共类库参照已有类库引用,以下主要对项目级Namespace命名提出参考建议:

YesHJ.Ucenter 用户中心
YesHJ.Cms 网站内容系统
YesHJ.Class 网校
YesHJ.Bulo 社区
YesHJ.Shop 网店
命名空间建议: YesHJ.{ProductLine}.{Appname}.XXXX =>例如:YesHJ.Bulo.KaoDian.XXXX

1.3、变量、方法命名

  • 私有变量及方法参数使用camel命名(第一个词首字母用小写,其它词首字母用大写)
  • 公共变量、方法、类使用Pascal命名(单词的首字母用大写)
  • 公有变量尽量使用Property ,慎用Public Static变量;
  • 变量命名要有意义:拒绝无意义的变量a,a1,b,k等;
  • 典型的增删改查方法命名如下:比如获取GetUserList
  • 用名词或名词短语命名属性;

1.4、文件、文件夹命名

  • 目录命名建议和Class命名要求一致,不要出现“_”和“小写”开头,已经用小写的不需要调整,保证命名空间的命名符合标准即可。
  • 特殊或者系统文件夹可保持大写方式,比如App_Code、App_WebReferences等;
  • 文件命名一般采用小写,应用加下划线方式命名。
  • 页面的命名和Class命名要求一致,注意不要小写开头。

【Web服务】

1.URL命名:

老的Api方式:app.hujiang.com.hjdns.net => {appName}.hjapi.hujiang.com (内部域名解析) 还有一些是使用 {appName}.yeshj.com

2.传参:不要暴露参数类型和参数值

不好的例子:
http://bulo.hujiang.com/service/GetUserFace.ashx?ver=2013%E5%B9%B44%E6%9C%8816%E6%97%A5%20 %E4%B8%8B%E5%8D%885:07:52&userId=12644342&callback=jQuery17207177500906400383_136610325 2485&_=1366103272413

应该是:
http://bulo.hujiang.com/service/GetUserFace.ashx?token=asdfkjsldjwlejfsldjflsdjlf&callback=jQuery17207177500906400383_1366103252485&_=1366103272413

3.类型和应用场景:

  • Web Service:传统用法,不宜调用太频繁。注意要有异常保护,即使不返回结果,也不要影响页面的其他功能,尽量用异步。
  • Rest Service:一般参数要保护;同样不宜调用太频繁。尽量用Json做数据格式。
  • WCF Service:适用于高安全、频繁调用,同时不能直接产生数据库关联的场景。

【代码风格】

2.1、代码前置后置

代码前后端分离:(code-behind)
好处,逻辑比较清晰,容易进行重构。
缺点:发布、维护繁琐一些。

今后新项目必须采用代码后置(code-behind),不要再使用单页面(single-page code ),特别是UserControl等需要复用的,自己在维护代码时,修改单页面程序时,要把它改成code-behind。

建议:

  1. 需要简化前台代码的数量和复杂度,必要时需要分离出独立的Service层,前端的C#代码仅仅用来做交互性的操作,不要包含太多复杂逻辑。
  2. 新项目尽量采用Web Application Project,不建议使用Web Site Project。

2.2、注释

  • 逻辑理解注释,采用//加注释语句
  • 写在注释语句之前一行或者紧跟着注释语句后同一行
  • public,protect函数或者属性注释采用/// VS自动添加注释模式,
  • 所有共有变量和共有方法都需要注释,类库中的protect和public的类要加类头注释

2.3、书写格式

  • 在程序代码间一般不要连续留空两行
  • 如果一个函数的参数很多,要么一行全部输入,要么一行一个参数
  • 不要用空格缩进,统一用制表符缩进
  • 对于一些比较长的块,使用#region 和#endregion 来括起来
  • 单行代码要 < 80个字符
  • C#代码中的SQL要排版,方便阅读和维护;格式:参照数据库开发规范。

【程序开发安全与性能策略】

  • 参数检查 常见的像字符串参数,一般调用 String.IsNullOrEmpty函数来检查,或按照需要自己编写函数检查。 对于数字、电话号码、身份证号等检查采用公用类库方法进行服务器端检查。 对实体对象的ToString操作,一定要先做非空判断,或者调用Convert.ToString方法;
  • Sql注入防范 对外部传入参数进行合法性检查,比如传址、表单、cookies数据; 写数据库相关服务时,非特殊情况,必须使用参数化方式传递变量参数; 敏感表用存储过程操作,限制连接sql权限,只赋予Select以及存储过程执行权限更新数据;
  • 对于数据库连接的策略是尽早释放,如SqlDataReader用完之后一般采用Using自动释放连接,或者要主动调用Close方法关闭连接。
    对于连续的ID,要防范恶意用户做推测性的攻击行为: 可以使用Framework里面的FakeIDHelper、GuardIDHelper类进行伪装。
  • 日志:

    • 比较大的项目,我们需要选用Log4NET这样的比较成熟的日志组件。小一些的项目也可以使用.NET内置的System.Diagnostics里面的日志方法。
    • 除了要建立ErrorLog日志之外,建议对每个后台服务的执行情况和执行时间做必要的监控: 可以写Log文件、数据库、远程日志服务等,但是要考虑尽量减少对性能的影响,增加可维护性。 特别是首次上线后,要通过监控,密切观察系统的运行情况,了解系统的性能瓶颈、产生原因等,方便对系统进行持续性优化。

【高级应用】

1.1 缓存策略

分布式缓存和.NET缓存测使用场景:

  • .NET Cache:要求更快,访问频繁,数据量较大的用.NET Cache;
  • Memcached:有一致性要求(多台Web server),数据量较小,读写不是特别频繁的用Memcached;大并发访问需要加锁,注意加锁方式。用检查Memcached的Key是否存在是锁不住的。
  • Redis:有一致性要求,数据量中等规模,读写比较频繁的可以考虑用Redis;

1.2 数据访问层的选择:

  • 网站或应用的访问量大小、访问特点:逻辑是否复杂,实时性要求如何?
  • 数据源的情况:是NoSQL还是关系数据库
  • ORM的选择:提倡选用轻量级的ORM框架:FlunetData http://fluentdata.codeplex.com/ 除非有特殊要求,今后大访问量的应用一般不要使用NHibernat和EntityFramework等比较重的ORM技术。

1.4 AOP:

推荐使用Postsharp,效率比较高。

【运维和部署】

Web Server的部署环境:

  • Windows 2003 64位+ II 6 +.NET 3.5
  • Windows 2008 R2 64位+ II 7 +.NET 4.0 or 4.5

添加新评论