标签：style 使用 sp 文件 数据 on 问题 代码 时间
应用程序框架是用来支持应用程序开发的，它就好像一个保姆，在开发的每一个细节对程序员呵护倍至。那么，应用程序框架应该包含哪些内容呢？原则上来说，只要期望能够复用的所有东西，都可以进入你的框架。
开发新手与经验丰富的老手，其中一个重要的区别在于复用代码的方式不同。开发新手喜欢复制粘贴，而老手则更倾向于抽象和封装。曾经听人说，复制代码是魔鬼，为什么这么严重？
当你把那几句代码四处复制粘贴，然后突然意识到需要修改一下，这时候悲剧就发生了，你需要找到所有的代码，然后挨个地方的改，这是一个体力活，如果粘贴的地方有点多，比如100个地方，那就要忙一阵子。不过这还不算严重，更严重的问题是可能会有漏网之鱼，一个不留神，漏掉一个地方，当场肯定发现不了，因为你不大可能重新把代码检查一遍，更不要说把所有的地方都测试一遍。这就埋下一个地雷，就看什么时候踩到了，不过一般都不会在短期内发现。有可能过了三个月，有人发现一些很诡异的BUG提交给你，于是你打开VS，不停的断点调试寻找错误，花了大把时间之后，终于找到了，然后你笑着告诉自己，“没什么，上次漏了个地方没改，一个小BUG而已”。这就好比搞财务的，只是把小数点打偏了一位，对他来讲没什么，不是技术上有问题，但结果很严重。
如果经常被复制粘贴搞得莫名其妙，并想改善一下方法，说明你开始寻找解决方案了。对于复制粘贴，一般需要两个解决方案来应付。一是抽象和封装，二是根据模板生成代码。
哪些代码值得你封装？
首先考虑技术性的，比如文件上传下载，为什么要封装这些东西呢，那几句代码虽然不复杂，但你随时都能记得住吗，每次敲这么多代码不累吗，关键一点是，你是否需要复制粘贴呢。技术性的代码被封装以后，有一个响当当的名词——公共操作类，一般会在类名上加个Helper，表示帮助类。当形成了大量的公共操作类后，开发过程将大幅简化，它的目标是帮助你摆脱技术上的困扰，把更多精力放到业务上。
第二，考虑如何增强现有系统，比如通过扩展方法来提供更易用API。另外需要提供系统健壮性支持，比如日志跟踪，全局异常捕获、依赖注入、安全机制等。
第三，考虑哪些代码是每个业务类都具有的，抽象到基类，如果使用DDD架构，按DDD分层架构和构造块建立基类。
第四，对表示层的支持，可以对界面上的元素进行封装，以提供更独特的功能。比如某个按钮，需要有权限才显示，这时候你需要在表示层写一个判断，如果他没权限会隐藏这个控件，如果很多地方有类似需求，你就会发现表示层充斥大量的判断。把这些独特功能封装到控件中，可以获取更清晰的代码。
第五，看看业务上有哪些类比较通用，例如地址，包括国家、省份、城市、区县、街道、 邮政编码等信息，哪怕换一个项目，地址还是这些内容。另外将行业性的东西抽取封装，很多项目都可以受益。
第六，对第三方业务系统进行封装，比如第三方应用平台、硬件设备提供的API等，封装之后，使用第三方接口，就好像调用本地的API一样。
第七，把一些通用性强的模块封装起来，可以显著提升进度，比如权限管理，部门管理，员工管理。
当你进行了各个层面的抽象和封装之后，你会发现还是有相当一部分代码需要来回复制粘贴，仔细观察这些代码，它们的结构都差不多，可能只是由于数据库的字段不同，所以要改一下，最常见的就是CRUD操作。由于信息系统归根结底就是CRUD操作，所以几乎每个数据库的表都会有对应的操作。不过还是那个老毛病，复制粘贴的方式不保险，而且效率低下，特别是在分层架构下，问题更严重，因为代码要跨越很多层。更好的方式就是创建模板，通过代码生成器要建立基础代码，不仅速度快得多，而且质量有保障。
下面，总结一下应用程序框架应该包含的范围：
配套代码生成器
总之，能复用的都放进去。
标签：style 使用 sp 文件 数据 on 问题 代码 时间
原文地址：http://www.cnblogs.com/xiadao521/p/4070962.html
