标签：blog http 使用 数据 问题 cti 代码 log sp
最近刚开始着手做项目，在后期开发的时候遇到不少预期之外的问题，而且工期也超出预算不少。反思了一下，主要是做的项目少，前期需求分析不明朗，当然对于框架也没有意识。凡此种种。当然，遇到问题就要去想办法解决，于是看了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/
标签：blog http 使用 数据 问题 cti 代码 log sp
原文地址：http://www.cnblogs.com/code-charmer/p/3947470.html
