标签：基本 安全 数据表 传参 关系 读写 拼接 服务层 增加
对于B/S都是MVC好不好 不多说了，反正大家都这么用
这里简单说下C/S
首先常用的几种：
分层的目的是为了实现高内聚低耦合，而我嘛就是想让代码好看一点……
如何分层才能够比较快速地开发呢？好吧似乎两者根本没有任何关系
没有吗？有吗？
可以说没有，但实际上应该是多多少少有点的(咋感觉像莫须有的赶脚)
以我的MyRapid为例，说下我的分层
首先是WCF实现C/S分离，有人把C/S分开也算一种分层（呵呵）
这里要涉及到分层了，有的人在服务端分层，WCF作为Control 下面可能有BLL， BLL再下面还有一个DAL，这种情况个人认为就会影响开发速度了，团队里面多个人同时在修改服务层，没经历过真心不知道有多痛苦，小心不能再小心了，每次修改一定要先更新到最新的，还要吆喝一下我改了哪个，有修改过的抓紧上传，要不该冲突了
所以说分层还是和开发效率有关系的……
我的解决方案是WCF写死，不动，WCF只有2个方法，读、写，最近增加了一个执行，其实用读也可以实现，读就是执行Sql并且返回数据表，写就是执行但是不返回(也可以返回int)，执行就是执行后不管了，有点异步的意思(整体感觉有点SqlHelper再次封装的意思)
那么需要考虑的就是读写的参数问题了
这个时候先来一个前端UI，下面跟一个BLL，在下面一个DAL，DAL调用的不再是SqlHelper而是WCF(WCF数据源是不是就是这个思路？没深入了解，嘿嘿)
这样在一定程度上解决了团队开发的版本冲突问题，当然也存在了业务逻辑暴露的危险，必定BLL、DAL都放在了 客户端，在一定程度上牺牲了安全性，至于解决方案以后再说
再来说下DAL的优化，BLL个人没有发现优化的可能，倒是发现不少毫无疑义的转接，前面调用一个GET() 到了BLL BLL啥也不干直接调DAL的GET() 也有优化空间，不过都是代码生成器，实际上没什么优化价值
直接说DAL的优化，DAL说白了就是传Sql语句的，现在用EF的话都不怎么需要了，我的框架没有用EF所以还是要说下(关于EF的优缺点欢迎百度，不多说了)
首先Sql的参数，有人喜欢拼接字符串，我是强烈反对的，参数化查询的优点可以直接百度
如果使用参数化查询这里涉及到一个空参数的问题，我的解决方案是
WHERE 1 = 1
AND ISNULL(A.Page_Name,‘‘) LIKE ‘%‘+ ISNULL(@cPage_Name,ISNULL(A.Page_Name,‘‘)) +‘%‘
可以看出如果是空的化会过滤掉，当然缺点也是有的，就是会多过滤一次筛选 可能会导致查询速度下降，再实际测试时候没有发现问题，上百万级时没试过(待会试试)
代码也更好看了 再VS里面是红彤彤的一大块 没有 sb.Append什么的
然后就可以将实体用反射传参过来了
基本就是这些 欢迎大神补充
标签：基本 安全 数据表 传参 关系 读写 拼接 服务层 增加
原文地址：http://www.cnblogs.com/cedtry/p/7940404.html
