先记下这些小毛病，后面在慢慢回味-第二篇
- 摘要：理解需求：理清业务逻辑，根据业务场景，选择合适的解决方案按照开发语言的编程规范开发对象的序列化：处理ajax请求时，一般都是将后台要返回的数据序列化成json对象，这样便于页面获取json数据如果后台返回给页面的数据已经是json对象了，但是前台仍然获取不到，可以用$.parseJSON(data)；在jquery3.0以后，请用$.parseJSON已经过时，不建议使用，将字符串解析成JSON对象，请使用原生的JSON.parse方法来代替。在三层架构中，DAL和BLL的创建
- 标签：
- 理解需求：理清业务逻辑，根据业务场景，选择合适的解决方案
- 按照开发语言的编程规范开发
- 对象的序列化：处理ajax请求时，一般都是将后台要返回的数据序列化成json对象，这样便于页面获取json数据
- 如果后台返回给页面的数据已经是json对象了，但是前台仍然获取不到，可以用 $.parseJSON(data)； 在 jquery3.0以后，请用$.parseJSON已经过时，不建议使用，将字符串解析成JSON对象，请使用原生的JSON.parse方法来代替。
- 在三层架构中，DAL和BLL的创建，都要以数据来源为依据，不能根据UI的要求去创建对应的BLL文件；数据库的每一张表，对应一个实体类，对应一个DAL，对应一个BLL，这样可以保持整个项目结构比较简洁，便于后期维护，不要到处创建BLL。对于通用的操作，可以写在BaseDAL(或者BaseBLL)中。asp.net MVC亦是如此。
- 数据模型(实体类)以业务为主，既有通用性，又具有独特性。如果数据模型(实体类)不满足当前业务，可以写一个扩展类，继承于当前的数据模型(实体类)
- 在三层架构(或ASP.NET MVC中)，尽量做到各层各司其职。
- 数据库只用来存储据(少写存储过程，少写SQL)
- model层的实体类，只用来存与数据库每张表对应的实体，以便各层用model传递数据
- DAL层操作数据库，如果用ado.net操作数据库，尽可能的少用DataTable；推荐使用EF框架，尽量减少与数据库的交互，合理使用缓存
- BLL层，用来处理从DAL层拿到的数据，主要是从业务的角度去处理
- UI层，用来做展现，在将数据展现给UI层之前，最好是将数据序列化为json对象，便于前台处理
- 对于数据的增删改，不要从页面上取数据，所有的数据都从数据库来。例如要修改某个用户的信息，这个时候后台一般有两个editUser的方法，示例如下：
- [get]
public User EditUser(string UserID)
{
//这个方法的作用是：1.从数据库获取用户信息
2.当数据获取到之后，进行下一步操作(跳转到修改页面，或者是弹出一个框)
3.将获取到的数据，传递给真正用来提交数据的那个方法
}
[post]
public bool EditUser(User user)
{
//这个方法，才是真正将修改后的User信息，提交给服务器
}
- web端需要提交的数据，尽量放在form里，然后用$("#formid").serialize()方法，将表单数据封装成json
- 所有的增删改操作，都最好有日志记录，对数据的删，一般都会保留原有的数据，新增一条新纪录,做软删除。
- ambda表达式其实是对当前对象的迭代，使用时，要明白每一个操作之后返回的对象是什么。
- EF框架中的lambda表达式，select和where的顺序在写法上不分先后，因为是懒加载，用的时候(比如调用ToList()方法)才会生成一条完整的sql。select是必须的，否则会出异常。
- 普通的lambda表达式，不操作数据库的时候，只是对当前数据的筛选和计算。要注意select和where之间的顺序，select和where 都不是必须的
- JS比较大小，要用parseint()和parsefloat() 将字符串转换为对应的int或float类型之后，才能做比较
- sqlserver的递归和游标，使用时注意全局游标与本地游标的区别
- 浏览器调试，注意打断点的位置
- 理解ajax的异步原理和执行过程
- 数据库建表，要避免表的冗余，相同结构的数据，可以放在同一张表中做好标识
- 配置表要具有通用性
- 学习项目结构(架构)设计，提升项目的性能。项目结构要具有可扩展(接口式编程)，易卸载的特点
- 系统的通用部分：全局异常处理(可提高系统的稳定性)、日志监控(便于快速定位问题)、用户权限配置、数据导入导出、邮件服务
- 代码中尽量不要写绝对路径
- 如果程序本机正常，在服务器上运行异常，解决办法：1.查看服务器系统日志 和IIS日志 2.用VS进行远程调试
相关文章
