最近的一些开发想法

实习近三个月 确实真正的企业级开发要比之前的小打小闹正式不少 以至于现在有打算重写配棉系统的冲动

 

如果是局域网的项目 带宽大 尽量能不要AJAX就不用AJAX 这里指的是原生的AJAX 因为之前开发都是用jquery做的AJAX 其实和原生的差不了多少 但是相对于ASP.NET自己提供的AJAX控件就要差多了 关键还是在于不好调试 或许是因为我没有找到好的调试方法吧

 

关于反射 这个东西是把双刃剑 记得刚刚接手项目的时候从UI获取数据转化为实体类的时候我是这么做的 因为数据以表格形式输入 给每一个单元格加一个class 代表其实体类的属性名称 然后用jquery解析 拼接JSON AJAX到后台 反序列化 结果就是最后调试死活看不出是啥错误

其实关于上面一点 也怪当时水平不够 不理解程序的调用堆栈 现在想想 当初完全可以通过看一下调用堆栈来判断哪儿出错了 这里有一个对.net框架的比较不好的看法 就是反射invoke某个方法的时候不应该捕获该方法的异常 或者在抛出的新异常中包含原来异常的信息 可能在这块儿 微软的设计师有别的考虑吧

不过用反射倒是可以满足一下自己的小聪明 由于不会用CODESMITH写模板 于是自己用反射写 由于项目中的实体类包含字段多大三十多个 而且数据库中直接产生的entity不满足业务需要 有时还要与自己扩展的entity做mapping 此时就可以用反射写的代码生成器生产相当一部分代码 同时 数据绑定时候的代码也可以生成很大一部分

 

关于框架 说实话这是个很虚的东西 同事是这方面的大牛 对于我的学习帮助甚大 对于分层也有了更好的理解 鉴于目前强大的ORM工具 事实上我们已经可以少做很多之前很繁琐的事情 具体来讲 由orm工具来生成最基础的model层 就像linq to sql做的 然后 在其上建立repository层 该层与model层作用 发生实质性的CRUD操作 同时更为重要的是 所有与数据库进行的操作都在这层进行

有时候一个结果需要查询多个表 组装多个实体类 这种粗粒度的操作就由所谓service层来完成 并且 由于orm工具返回的结果都是对象 因此就可以很好的做的两个层之间的解耦

service层另一个好处就是可以封装结果 我的做法通常是写一个operationResult的类 其中封装了操作的结果(IsSuccess) 以及一些操作时产生的信息 具体来讲可以是比如说某个用户未找到啊之类的  将这些封装到一个list<T>之中 最后 封装取回来的数据到一个泛型集合 如此一来 就大大增强了service面对需求变更的能力

 

关于泛型 说实话 我都感觉自己现在成了那种手里有榔头 啥都是钉子的感觉 似乎在抽象的更高一层就是泛型 但有时又为泛型所困扰

 

关于.net底层 了解一下.net底层对于开发绝对是有好处的 很可惜的是很多工作了几年的人都没这个概念 一直停留在拖控件的层面

当然了解.net底层不仅仅是让你脱离拖控件 更高一层还有许多好处 诸如调试时候分析错误等等 重点是你对每一行代码具体在内存里面怎么运作 如何在CLR控制下执行都有个清晰的概念 这对写出强健的程序是很有帮助的

 

关于linq to sql 这是个好东西 省了很多事情 对生产效率有了一个极大改进 最大的就是我不用再自己写sql分页了 但是也有不好的 便是他对于外键关联的处理 其中很多是我觉得莫名其妙的 所以在看asp.net社交网站开发这本书得时候发现作者也是这样认为的我感到异常欣慰

 

关于一些教训  重要的业务类还是要做mapping的 不能直接拿数据库中产生的实体类 其次 在取数据的时候 尽量针对试图来取 而不是直接通过表 可以省去很多通过ID查NAME的事情

 

就写这么多 三个月来的工作经验 算算也不少了