油水井图片库开发总结

      锦州采油厂油水井图片库（下称图片库）是一个很小的项目。是一个类似wiki的图片搜索管理网站。在项目中使用了一些新的概念，使其成为迄今为止结构最为清晰的一个项目。
      一、仓储模式和增删改查
      仓储模式是一个很老的概念了，抛开领域模型的概念。仓储应该是将持久层（一般是指数据库）中的实体（一般是指数据库中的表）映射为编程上下文中的集合。这样做的主要好处有三点：
      1、对上层隐藏持久层的细节
       这种隐藏一般在多人开发的较大型项目中才能体现出来，一般是为了保护数据库的安全。
      2、隐藏持久层实现
      在实践中，往往使用某种ORM框架来实现仓储。如EF或NHibernate等。如果因为某种特殊需求改变了持久层实现，对上层而言是透明的。可以保持上层的稳定性。
      3、无需切换思维
      数据和数据源被映射为程序语言中的集合、类和接口，以C#为例，我们可以使用linq语法随心所欲的操作数据。而不需要去理会SQL实现的细节。
    
       当然上述好处都是理论上的，实际开发过程中。业务层开发人员不可能完全不了解数据库知识。比如多个数据库操作时，我们也会在业务层中使用事务来保障数据的一致性。个人认为仓储模式最大的好处，是重新规划了数据处理的方式。在长期的实践中大家都知道，数据的四种操作：增删改查，其复杂程度是完全不一样的。增、删、改这三种操作都是针对单表而言的，和仓储模式可以很好的契合，仓储模式也是针对单个实体的。但是数据查询的复杂度要远超前三种操作。在实际业务中，我们经常需要进行各种复杂的多表查询。这种多表查询，以往都放到DAL层去处理，视为数据存取逻辑的一种。在实操过程中发现这样会让DAL层变得非常脏，而且很难清晰的划分业务和数据存取的边界。
       对于这些问题，仓储模式的解决方案是这样的。向上层传递一个 IQueryable<T> 泛型接口，业务层将这个接口视为一个数据源。从而可以灵活的进行联查和各种自定义查询。从而保证了仓储层真正的不需要变动，可以适用于所有情况。
        以往都将联查和分页视为数据存取逻辑，在仓储模式下。表联查和数据分页都放在业务层中进行，毫无疑问是业务代码。
        这样一来就将系统划分为了：仓储-业务-UI 三层

        二、使用DTO进行数据传递
       DTO(Data Transport Objects)即数据传输对象，以往我们直接把数据库实体对象暴露到UI层，使用匿名对象来构造传递到页面上的数据。这样虽然很简单，带来的问题也很大，业务逻辑分散到了UI层中，而且把数据库实体暴露给UI在团队开发中也是不安全的。此外DTO作为参数包装也可以从UI层向业务层传递，这样业务方法的参数就显得非常干净，在实际操作中，使用DTO可以使传递的数据清洁干净，没有冗余。

        三、存在的安全漏洞
       1、图片安全
       MVC自带的窗体身份验证可以很好的保障登录安全，由于图片库中开启了图片上传功能，使得上传图片的安全，成为一大隐患。商业网站中都有专门的杀毒防护程序对上传的文件进行筛选甄别，以防伪装为图片文件的病毒获取上传目录权限，进而攻破服务器。这里由于技术水平和人力，未能做图片杀毒处理。只依赖于服务器自身的杀毒程序。
       2、图片地址转换
       在将图片绝对地址转换为网络地址的时候，未做路径遮挡。对于有经验的程序员来说可以很容易的猜测出服务端目录结构。而且对图片的访问权限是公开的，服务端也未作任何限制，这也是一个安全隐患。