Mikel

[转载]利用log4net记录操作日志 – justconnor – 博客园. 1，目的：将用户操作日志写入SQL server 数据库中 2，实现步骤： 一，下载log4net.dll （推荐从官网下载 http://logging.apache.org/log4net/download_log4net.cgi） 二，在项目中引用 log4net.dll 三，添加一个配置文件：我这里命名为 log4net.config（也可以在web.config里面配置为便于管理故新建了一个配置文件） View Code <!–?xml version="1.0"?–> <section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net "></section> <!–这里是表示是记录1 条到缓冲区，满1条后再写入SQL server 可根据需要自定义配置–> 四，在项目的 AssemblyInfo.cs 文件的指定log4net 的配置文件路径 [assembly: log4net.Config.XmlConfigurator(ConfigFile = "log4net.config", Watch = true)] 五，自定义记录函数 View Code 　　public static void Operate_Log(string operateType, string describe) { log4net.ILog logToSQL = log4net.LogManager.GetLogger("iNotes"); [...]

[转载]MVC与三层架构的区别 – 小孤狼 – 博客园. 在此之前对MVC和三层架构没有一个太明确的认识，不知道它们之间有什么异同点，今天仔细研究了一下。 首先说三层架构： 1、表现层（UI）：通俗讲就是展现给用户的界面，即用户在使用一个系统的时候他的所见所得。 2、业务逻辑层（BLL）：针对具体问题的操作，也可以说是对数据层的操作，对数据业务逻辑处理。 3、数据访问层（DAL）：该层所做事务直接操作数据库，针对数据的增添、删除、修改、更新、查找等。 它们之间存在一种引用依赖关系： 再说说MVC MVC是 Model-View-Controller M是指数据模型，V是指用户界面，C则是控制器。 视图V 视图是用户看到并与之交互的界面。对老式的Web应用程序来说，视图就是由HTML元素组成的界面，在新式的Web应用程序 中，HTML依旧在视图中扮演着重要的角色，但一些新的技术已层出不穷，它们包括Macromedia Flash和象XHTML，XML/XSL，WML等一些标识语言和Web services.如何处理应用程序的界面变得越来越有挑战性。MVC一个大的好处是它能为你的应用程序处理很多不同的视图。在视图中其实没有真正的处理 发生，不管这些数据是联机存储的还是一个雇员列表，作为视图来讲，它只是作为一种输出数据并允许用户操纵的方式。 模型M 模型表示企业数据和业务规则。在MVC的三个部件中，模型拥有最多的处理任务。被模型返回的数据是中立的，就是说模型与数据格式无关，这样一个模型能为多个视图提供数据。由于应用于模型的代码只需写一次就可以被多个视图重用，所以减少了代码的重复性。 控制器C 控制器接受用户的输入并调用模型和视图去完成用户的需求。所以当单击Web页面中的超链接和发送HTML表单时，控制器本身不输出任何东西和做任何处理。它只是接收请求并决定调用哪个模型构件去处理请求，然后再确定用哪个视图来显示返回的数据。 举一个简单的例子来说明MVC MVC就像我们小时候玩的那种卡带式游戏机，Control是主机，一般来说我只要买一个主机就行了，只要它不坏，我可以一直玩这类的游戏。 View则是电视机和游戏手柄，电视机是可以独立工作的，它不管输入的是电视信号，影碟机信号，还是游戏信号，它只管显示，而且它决定显示的效果，如果我 想要一个尺寸更大的或者显示效果更好的，我只需要换一个电视机可以了，游戏手柄也可以换的，是普通的还是带震动的。Model则是游戏机的卡带。它决定我 玩什么游戏，是魂斗罗还是超级玛丽。而且游戏机的主机和电视机的生产厂家永远不知道将来在上面会运行什么游戏。卡带中可能会有游戏代码和存储单元，都根据 游戏的需要而设计。 最后在说说他们之间存在的区别 1.三层架构中，DAL(数据访问层)、BLL(业务逻辑层)、WEB层各司其职，意在职责分离。 2.MVC是 Model-View-Controller，严格说这三个加起来以后才是三层架构中的WEB层，也就是说，MVC把三层架构中的WEB层再度进行了分 化，分成了控制器、视图、实体三个部分，控制器完成页面逻辑，通过实体来与界面层完成通话；而C层直接与三层中的BLL进行对话。 3.MVC三个事物之间并不存在明显的层次结构，没有明显的向下依赖关系，相反View和Model往往比较独立，而Control是两者之间的桥 梁，它们更像是横向切分，因此MVC中每个块都是可以独立测试的，而三层结构中，上层模块的运行测试势必要提供下层代码或提供相同接口桩。 为什么要使用 MVC 首先，最重要的一点是多个视图能共享一个模型，现在需要用越来越多的方式来访问你的应用程序。对此，其中一个解决之道是使用MVC，无论你的用户想要 Flash界面或是 WAP 界面；用一个模型就能处理它们。由于你已经将数据和业务规则从表示层分开，所以你可以最大化的重用你的代码了。 由于模型返回的数据没有进行格式化，所以同样的构件能被不同界面使用。例如，很多数据可能用HTML来表示，但是它们也有可能要用Adobe Flash和WAP来表示。模型也有状态管理和数据持久性处理的功能，例如，基于会话的购物车和电子商务过程也能被Flash网站或者无线联网的应用程序 所重用。 因为模型是自包含的，并且与控制器和视图相分离，所以很容易改变你的应用程序的数据层和业务规则。如果你想把你的数据库从MySQL移植到Oracle， 或者改变你的基于RDBMS数据源到LDAP，只需改变你的模型即可。一旦你正确的实现了模型，不管你的数据来自数据库或是LDAP服务器，视图将会正确 的显示它们。由于运用MVC的应用程序的三个部件是相互独立，改变其中一个不会影响其它两个，所以依据这种设计思想你能构造良好的松耦合的构件。 拿一个简单的登陆模块说，需求是你输入一个用户名、密码，如果输入的跟预先定义好的一样，那么就进入到正确页面，如果不一样，就提示个错误信息“你Y别在这儿蒙我，输入的不对！”。 V 这个小小的模块中，起始的输入用户名密码的页面跟经过校验后显示的页面就相当于View C 而这里还需要一个controller页面，就是用于接收输入进来的用户名密码，还有经过校验后返回的一个flg（此flg就是用于判断你输入的是否正确，而跳转到相应的页面的） [...]

[转载]InfoQ: 程序员开发大型应用程序的技巧. 假如你是一名Java开发者，正在开发和维护包含2000个类并使用了很多框架的应用程序。你要如何理解这些代码呢？在典型的Java企业项目小组 中，大部分能够帮你的高级工程师看起来都很忙，文档也很少。你需要尽快交付成果，并向项目组证明自己的能力。你会如何处理这种状况呢？这篇文章为开始开发 新项目的Java开发者提供了一些建议。 相关厂商内容 Visual Studio 11 Beta 和 .NET Framework 4.5 Beta版免费下载中！ 1. 不要试图一下子搞懂整个项目 仔细考虑一下，为什么你会想要先理解项目代码呢？大部分情况是有人要求你修复一个bug，或者增强系统已有功能。你要做的第一件事情不是理解整个项目的架构。当对项目进行维护时，这样做（理解整个项目架构）可能会对你造成巨大的压力。 即便是有10年编程经验的Java开发者，也无法理解项目的核心工作机制，尽管他们可能已经在这个项目工作超过一年（假设他们并非最初的开发人员）。比如，对于认证机制或事务管理机制还是缺乏确切的认识。 他们是怎么做的呢？他们对于自己负责的部分非常了解，并且能够交付价值给小组。每天的交付价值远比了解一些以后还不确定有没有的东西重要的多。 2. 关注于尽快交付价值 那我是要打消你对于理解项目架构的热情吗？完全不是。我只是要求你尽早地交付价值，一旦你开始一个项目，搭建了开发环境，你就不应该花一两周时间才 交付内容，无论它的规模大小如何。假如你是一位有经验的程序员，却两周都没有任何交付，你的经理怎么会知道你是真的在工作，还是在看新闻呢？。 所以交付能够将事情变得简单。不要认为在做有价值的交付前，你必须理解整个项目。这是完全错误的。加一段JavaScript的验证代码对业务就很有价值，经理能够通过你的交付对你更加信任。这样能够向上级领导证明你的贡献以及员工价值。 日复一日，在不断修复bug及增强功能之后，你就能够慢慢开始理解项目架构。不要低估对系统方方面面理解时需要花费的时间。花3到4天理解认证机 制，2到3天理解事务管理。这些都是依靠之前的相似项目的经历，但关键还是要花时间才能透彻的理解。要在日常工作中挤出时间，不要向经理要求特定的时间来 做这些。 找找项目是否有一些有效维护的单元测试用例。有效的单元测试用例是理解大型项目代码很好的途径。单元测试能够帮助你理解代码片段，包括一个单元的外部接口（单元如何被调用以及返回内容）及其内部实现（调试单元测试比调试整个实际用例简单许多）。 你如果能够很好的理解一些内容，那么就写些笔记，或者画些类图、时序图、数据模型图等，以便你或日后其他的开发者可以进行维护。 3. 维护大型项目所必须的技能 你能从事当前的工作，必然已经具有良好的java技术。我们来谈谈能够让你在新项目中良好表现的其他技能。大部分时间里，你在项目中的任务是修复bug和增强功能。 有两项很重要的技能能够在你维护大型项目代码起到帮助。 3.1 能够迅速发现需要的类 在任何维护活动中，无论是修复bug或增强功能，第一件事情就是识别出当前修复或增强的用例中调用的类。当你定位到需要修复或增强的类/方法，就已经完工了一半。 3.2 能够分析变更的影响 当你在完成必要的修改或增强工作后，最重要的就是要确认你的修改没有破坏代码的其他部分。你要用你的java技术及对其他框架的理解找出变更可能影响的部分。下面两个简单的例子详细描述了最后提及的情况：  当类A的equals()方法变更后，调用保存A实例的List的contains()方法时就会受到影响。若Java知识不够，就很难考虑到这样的影响。  在web项目中，我们假设“user id”保存在session中。新加入的程序员可能在“user id”中加入一些信息来修复bug，但是却不知道那会影响到 与“user id”关联的用例。 因此，既要深入了解Java语言，又要深入了解你在应用中使用的框架，这样才能分析出一个改变的影响。 当你提高了如上两个技能，尽管你对项目不是非常了解，但大部分的维护任务会变得简单很多。如果你想要修复一个bug，就会定位并修复这个bug，并且保证变更不会破坏项目的其他部分。如果你想要增强或加入特性，基本上你只需要模仿现有的特性，使用类似的设计。 在一个在线银行项目中，为什么“查看账户摘要”和“查看交易历史”的设计要有巨大的差别呢？如果你理解了“查看账户摘要”的设计，完全可以模仿开发出“查看交易历史”的功能。 就修复bug和增强来说，你不必完全理解所有2000个类的工作内容和代码驱动系统运行的原理。只要有上面的技能，你就能很快定位需要修改的代码，使用良好的java和框架技能修复，保证变更不会破坏项目的其他部分，然后交付，尽管你可能只知道一小部分项目的设计。 4. 使用工具找到所需变更内容以及变更产生的影响 继续我们尽快交付的主题，你应该寻找工具作为辅助，只需要对项目又很少理解，就能帮助你尽快实施交付。 4.1 迅速发现所需变更内容的工具 [...]

[转载]代码的坏味道 – david++ – 博客园. 代码坏味道：是指在代码之中潜在问题的警示信号。并非所有的坏味道所指示的确实是问题，但是对于大多数坏味道，均很有必要加以查看，并作出相应的修改。 1. 重复的代码 如果你在一个以上的地点看到相同的程序结构，那么当可肯定：设法将它们合而为一，程序会变得更好。 同一个class内的两个函数中含有重复的代码段 两个兄弟class的成员函数中含有重复的代码段 两个毫不相关的class内出现重复的代码段 注意：重复的代码是多数潜在BUG的温床！ 2. 过长的函数 拥有短函数的对象会活的比较好、比较长。 程序愈长就愈难理解 函数过长阅读起来也不方便 小函数的价值：解释能力、共享能力、选择能力 原则：每当感觉需要以注释来说明点什么的时候，我们就把需要说明的东西写进一个独立的函数中。记着，起个好名字！ 3.  过大类 如果想利用单一类做太多事情，其内往往就会出现太多的成员变量。 提取完成同一任务的相关变量到一个新的类 干太多事情的类，可以考虑把责任委托给其他类 注意：一个类如果拥有太多的代码，也是代码重复、混乱、死亡的绝佳滋生地点。 4.  过长的参数列表 太长的参数列表难以理解，太多参数会造成前后不一致、不易使用，而且你需要更多数据时，就不得不修改它。 原则：参数不超过3个！ 5. 发散式变化 我们希望软件能够更容易被修改。一旦需要修改，我们希望能够跳到系统的某一点，只在该处做修改。如果不能做到这点，你就嗅出“坏味道：发散式变化”或“坏味道：霰弹式修改”。 发散式变化：一个类受多种变化的影响 数据库新加一个字段，同时修改三个函数：Load、Insert、Update 新加一个角色二进制，同时修改四处 … 原则：针对某一外界变化的所有相应修改，都只应该发生在单一类中 6. 霰弹式修改 如果每遇到某种变化，你都必须在许多不同的类内做出许多小修改以响应之。如果需要修改的代码散布四处，你不但难以找到它们，也很容易忘记某个重要的修改。 霰弹式修改：一种变化引起多个类相应的修改 7. 依恋情节 函数对某个类的兴趣高过对自己所处类的兴趣，就会产生对这个类的依恋情节，造成紧耦合。 原则：判断哪个类拥有最多被此函数使用的数据，然后将这个函数和那些数据摆在一起。 原则：将总是变化的东西放在一块。 8. 数据泥团 有些数据项，喜欢成群结队地待在一块。那就把它们绑起来放在一个新的类里面。这样就可以： 缩短参数列表 简化函数调用 9. 基本型别偏执 代码中有很多基本数据类型的数据。 原则：如果看到一些基本类型数据，尝试定义一种新的数据类型，符合它当前所代表的对象类型。 10. switch惊悚现身 面向对象程序的一个最明显特征就是：少用switch语句。从本质上说，switch语句的问题在于重复。 原则：看到switch你就应该考虑使用多态来替换它。 11. 冗赘类 你所创建的每一个类，都得有人去理解它、维护它，但一个类没有存在的必要时候，就让这个类庄严扑义吧！ 原则：如果一个类的所得不值其身价，它就应该消失。 [...]

[转载]开发人员必备：微软发布示例代码浏览器 (Sample Browser) 第五版，让您尽享3500个示例代码 – Jialiang – 博客园. 今天早上，微软一站式示例代码库 携手MSDN和微软创新空间 正式发布了示例代码浏览器(Sample Browser)第五版。这是继去年10月第四版发布以来的一次重大升级。有了它，3500多高质量示例代码尽在手边，定能让您和您的开发工作如虎添翼！ 您不仅可以轻松下载到800多个来源于广大开发人员心声的微软一站式示例代码库(All-In-One Code Framework)示例代码，还能下载到400多个现最流行的Windows 8 Beta官方示例。还有数不尽，源源不断增加中的Windows Azure, ASP.NET, WPF, Windows Forms, Windows SDK, HTML5代码供你搜索下载。还等什么，快来将示例代码浏览器据为己有吧！ 安装：http://aka.ms/samplebrowser   新版示例代码浏览器主要新增功能包括 1. 示例代码搜索范围扩展至3500多高质量MSDN示例 新版浏览器可以搜索到3500多高质量MSDN示例。其中包括800多个来源于广大开发人员心声的微软一站式示例代码库(All-In-One Code Framework)示例代码，400多个现最流行的Windows 8 Beta官方示例，600多个Windows Forms, ASP.NET Silverlight，WPF示例。而且其示例代码数量正在每日剧增。   2. 增加示例代码收藏夹功能 你可以轻松地把喜欢的示例代码收藏起来。日后更方便地找到他们。 你不仅可以收藏示例，甚至可以将一个搜索收藏起来。比如”所有Visual Studio 2010 C++ 和UAC相关的示例”:     3. 自由的示例代码下载和管理体验 在上一版本的示例代码浏览器中，很多用户反应示例的下载不够灵活，比如用户可能只想下载那些下载过但有更新的示例代码，或者想重新下载某个示例。 新版示例代码浏览器讲给你带来全新的完全的自由度。让你尽情畅享示例代码。 在示例代码列表中，你可以单选或按住Ctrl / Shift [...]