摘要： 解耦，不仅只是对程序的扩展性而言，它可能还是你使用你的程序从一个层面向另一个层面提高的基础，请认真对待这个词语“解耦”。我相信，它将会成为与“SOA”，“分布式”，“云计算”，“KV存储”，“高并发”一样的热门的东西，我确信这点。以后，我将会继续关注这个词语“解耦”。今天主要是讲”代码之美“的一个话题，利用构造方法使你的对象进行一个可供注入的接口，这就是IOC里面注入的一种方式，即”构造器注入“。 1 /// <summary> 2 /// 统一实体 3 /// </summary> 4 public class EntityBase 5 { 6 7 ... 阅读全文

摘要： 一直在看“代码之丑”这个文章系列，心想，为得不来个“代码之美”呢，呵呵，今天做项目时，认为我的验证方法代码逻辑比较漂亮，所以就摘出来分享一下吧，今天讲的是方法的重载，事实上主要是说一下构造方法的重载。构造方法不同于其它方法，它没有返回值，可以有参数列表，可以是public,private,protected,internal等去修饰它，可以是加了static的类型构造方法，也可以是一个实例构造方法，可以自己去重载自己的构造方法可以去重载基类的构造方法美1：重载自己 /// <summary> /// 代参数的 /// </summary> ... 阅读全文

摘要： 事情是这样的，一个需求，根据当前登陆用户的角色，显示指定的信息列表。说明：角色与信息的状态有关系，如管理员，可以看到状态为1和2的记录，而普通用户只能看到状态是1的记录，对于这种需要，我们可以设置一张表来实现，当然直接写在程序中也可以Role_Status_R表如下：RoleID int Not nullStatus varchar(200) [可以使用int类型，但要求你的值必须是通过位移运算产生的]数据库结构如下：当然也可以设计一个字典来维护它们的关系，但不利于以后扩展，建议使用数据库方式，字典方式代码如下：1 //用户角色与状态关系字典 2 ... 阅读全文

摘要： 在上一篇文章中，告诉了大家数据库的三大范式，最基础的莫过于数据表中不能有冗余了，但今天主要说的已经“冗余”，而且，有时候冗余并非都是坏事！如，以下是一个大家伙，用户表user_info,它里面有用户的地址ID，如cityid,可能还有用户扩展表的信息，用户积分表的信息等等，这些信息至少需要三个表关联才能得到我们所需要的信息，而实际情况往往比这个还要复杂的多。这时，一种数据冗余的思想产生了，它相当于是用空间来换时间，即数据库在磁盘上占用的空间多了，但查询的性能提高了，这有时是我们可以接受的，规范固然重要，但有时也要具体问题具体去分析，对我们的user_info表进行改进后，可能是这样的结构use 阅读全文

摘要： 有时，理论与实践有一些差距，在做一个具体的事情时，我们应该以实际为核心，而不是把理论死搬上来，要“从实际出发”，呵呵。在数据库的世界里存在着三大范式，也就是规范，真正的关系型数据库应该尽可能的满足这些规范，但有时，我们却根据实际问题，需要违背这些规范，这个系列我将从实际项目中出发来与大家一起说说“反范式”的设计。设计数据库时，首先要根据业务，找出实体，确定实体间的关系。一个结构良好的数据库，让项目在开发的过程中可以顺畅，而一个结构不稳定的数据库则会导致项目在开发的过程中大量的修改代码。不能满面向对象的开闭原则（OCP）。有时，我们可能会经常为一些业务去添加表字段，而这并不是我提供的，建义大家， 阅读全文