05 2012 档案
摘要：最近一直忙于新公司的基础库建设和一些业务系统的开发，接触到了一些比较有思想的技术人员，在他们身上发觉到了很多值的深思的话题，也领悟到了一些比较有价值的经验在此与同行们分享一下也算是探讨一下吧；[王清培版权所有，转载请给出署名] 都说技术人员应该重视业务的学习和培养，只有精通业务了才能更好的发挥技术。其实我是不太赞成这句话的，为什么？从我的个人经历和经验来看，这是对的。当然世事无绝对，站在我们程序员的角度讲，我绝对建议技术人员始终要以技术为主业务为辅的观点。可能有些朋友要来火了，技术辅助业务应该是业务大于技术，凡事都是相对的。如果以业务为主，就等于把自己的小命送给公司管了，如果以技术为主那么小命还是自己保管的。这句话经历过的人才会懂，我就不解释了。
阅读全文
摘要：这篇文章讨论的概念其实比较简单的，但是在实际的项目应用中非常的重要和普遍。 我们的项目一般都是采用分层架构，有的三层有的可能五层或者其他的方式组织系统的架构，但是始终要将系统的架构按照模式设计，我们才能重用和接受维护。 随着ORM的流行和大面积的使用，行业内出现各种各样的ORM框架，有自己开发的有大型的软件公司开发的，基本在使用上都遵循了以实体为中心的概念，也就是围绕关系数据库中的表为操作对象。复杂的可能还包括连接查询多表操作等等。[王清培版权所有，转载请给出署名] 按照分层架构设计中的指导约束，我们应该尽可能的在系统模块之间采用Entity进行数据的传递。当然世事无绝对特殊性的项目可能没有这么简单
阅读全文
摘要：最近一直在忙新公司的基础库建设，对系统架构、开发框架及快速开发平台的设计实施都积累了一定的实践经验。 一般的中小型的软件开发公司，如果按照技术储备来衡量软件项目的技术含量的评定依据是可行的。但如果光是按照人头来衡量软件的技术含量是不可靠的。所以我们在选择跳巢的时候是选择大公司还是选择有技术含量的公司要根据自己的职业规划来。(本人最近体会到的一点跳巢经验分享给大家) 由于我现有单位技术部门刚刚成立不久，需要一些基础的开发框架，ORM当然是跑不了的。在后面的文章中我将陆续写下我在建设基础框架中的一些实践检验，里面可能包括对UI层的封装、基础控件的封装等等。我就废话少扯了，进入主题。 这篇文章的重点是无反射的ORM框架，为什么会有这样的想法？其实前不久群里的朋友就问了一些问题，他们在构建自己的ORM框架的时候频繁的在使用反射来编写功能。从跟他们的交流上来看他们似乎很喜欢使用反射来写功能，但是没有仔细的研究过
阅读全文
