最近刚开始着手做项目,在后期开发的时候遇到不少预期之外的问题,而且工期也超出预算不少。反思了一下,主要是做的项目少,前期需求分析不明朗,当然对于框架也没有意识。凡此种种。当然,遇到问题就要去想办法解决,于是看了empty老师关于搭建框架系列的文章,不过还是有好多地方不太明白,暂且记下来一些自己感觉值得注意的地方。后续会更新。
术语
T4模板 SubSonic ORM框架
1.
要接手开发一个项目,首先要问自己思想上准备好了没有?也就是说做为一个项目的主要执行人员,你清楚你在做什么吗?要实现什么功能?怎么实现?用什么平台、工具开发?涉及什么技术?和什么人一起开发?水平如何?可能会遇到什么样的困难?怎么解决?项目涉及什么业务?你了解这些业务流程吗?对性能与安全有怎样的要求?如何优化?你懂得代码安全与服务器安全吗?要写那些文档?怎么写?有没有开发计划?计划花多长时间?怎么控制进度?.
2. 要实现什么功能?怎么实现?
要实现的功能前面已进行简单的描述。
实现的步骤:将会按照软件工程所描述的步骤,首先会制定开发规范要求、编写需求文档、开发文档(总体设计文档)、详细文档(细化相关技术难点与算法,绘制相关算法、流程图表)、设计数据库、然后编码、测试、部署上线等,整个过程将会涉及很多文档的编写与维护工作,在实施过程中不断完善相应文档,并做好版本控制以及项目进度控制工作,做到项目需求的修改与变动都有法可依(有文档可供查询与查看),执法必严(严格控制开发进度)。
3.实际上编写文档就像写作文,只要条理清晰的讲述出相关内容,突出重点,不要偏离该文档主题就可以了。当然如果你能详细的将5个W2H原则说明清楚,再配上相应的图例(流程图),那就更棒了。
5个W2H原则说明:1.WHY ——为什么?为什么要这么做?理由何在?原因是什么?2. WHAT——是什么?目的是什么?做什么工作?3. WHERE——何处?在哪里做?从哪里入手?4.WHEN——何时?什么时间完成?什么时机最适宜?5. WHO——谁?由谁来承担?谁来完成?谁负责?6.HOW——怎么做?如何提高效率?如何实施?方法怎样?7. HOW MUCH——多少?做到什么程度?需要多少时间?数量如何?质量水平如何?费用产出如何?
4.日常开发的很多情况下为了复用一些共同的东西,会把一些各层都用的东西抽象出来。如我们将数据对象实体和方法分离,以便在多个层中传递,例如称为Model。一些共性的通用辅助类和工具方法,如数据校验、缓存处理、加解密处理等,为了让各个层之间复用,也单独分离出来,作为独立的模块使用,例如称为Common。
业务实体Model:用于封装实体类数据结构,一般用于映射数据库的数据表或视图,用以描述业务中客观存在的对象。Model分离出来是为了更好地解耦,为了更好地发挥分层的作用,更好地进行复用和扩展,增强灵活性。
l 通用类库Common:通用的辅助工具类。
在第5.2节中我们讲过可以将对数据库的共性操作抽象封装成数据操作类(例如DbHelperSQL),以便更好地复用和使代码简洁。数据层底层使用通用数据库操作类来访问数据库,最后完整的三层架构如图14-3所示。
图14-3 最后完整的三层架构
数据库访问类是对ADO.NET的封装,封装了一些常用的
重复的数据库操作。如微软的企业库SQLHelper.cs,动软的DBUtility/DbHelperSQL等,为DAL提供访问数据库的辅助工具类。
5.SubSonic是Rob Conery用c#语言写的一 个ORM开源框架,使用BSD软件授权许可(The BSD 3-Clause License)。它是一个实用的快速开发框架,通过非常简单的配置,以及附带的T4模板,就可以帮我们生成功能强大的数据访问层工具,让开发人员远离SQL语句的拼接,专注于业务逻辑的开发。
6。为什么多数公司会忽略需求分析的重要性,主要原因我觉得有三种,一是需求方也不明白自己要的是什么;二是沟通问题,需求方自认为讲得很清晰了,以为开发方相关人员明白它想要的,而开发方也自认为已经理解了需求方的要求;三是觉得需求很简单,不必要花太多时间浪费,早点开发早点完工,节省开支。
所以需求的采集,重点在于沟通与记录,要多提问多思考多论证。
怎么进行需求采集
在同用户的交流过程中收集各种用户的信息与要求,且第一时间将得到的需求整理成文字描述,一一记录下来。在需求采集的过程中,可以要求需求方提供相关的文档、报表、业务流程图等内容给我们参考,然后在这些基础上认真思考在软件上实现的UI大概样子,里面包含什么功能,可能存在什么问题或难点,及时与需求提出者做多次确认,看我们的理解是否是正确的,排除不合理的地方,明确各个业务流程与约束。
编写需求文档
需求文档的编写原则是:必须清晰明了描述要求,只描述做什么,不描述怎么做。
7、
创建数据库
1、 数据表设计要求
1. 数据库表名与字段名应遵守Pascal风格,包含一到多个单词,每一个单词第一个字母大写,其余字母均小写。(具体命名要求请查看第3章节)
2. 如果是关联表,则命名规则为R_表A_表B,如R_ProductInfo_Tag等。
4. 对于视图命名,规则为View_表A,视图由多个表产生,就用下划线连接几个表名,如View_ProductInfo_ProductClass。
5. 存储过程,命名规则为P_表名_存储过程功能名称。如P_ProductInfo_Add;如果该存储过程是很多表共用的,命名为:P_All_存储过程功能名称
6. 数据字段命名,也使用Pascal风格。当字段引用的是其他表字段时,使用表名_其他表字段名称,间用下划线隔开,命名规则:表名_单词。如ProductInfo表与ProductClass表关联的字段:ProductClass_Id,ProductClass_Name等。与外表的主键或相关字段引用时(包括状态值),须加同时添加外表所引用主键(或状态值)对应的名称,以方便查询时减少多表关联语句的编写,提高代码执行效率,详细请看《数据字典》中的设计。
8.
本框架主要有四种日志记录,分别是登陆日志、操作日志、手动收集异常日志和自动收集异常日志四种
http://www.cnblogs.com/EmptyFS/