关于分层的问题
我想问下，像网页上的控件要验证是否为空，或者验证其他条件，或者验证某个控件要符合什么条件这样的一些操作应该放在哪一层来写比较合适？？（我现在做的东西大概是根据petshop来分层的）

还有我在model层里能否加上一些加密的算法，还是model层的东西就什么也别加？请高手赐教，谢谢！！

------解决方案--------------------
验证空、格式 在表示层 或者 直接 写个脚本验证 
如果 是验证数据库中是否存在 有两种 一种是 ajax 另一种是到 bll 或者 dal 里面处理 看自己情况了
bll petshop 不太好 应该再分的详细点就好了 一个业务规则层一个业务表现层 
关于 model层数据 是否加密 这个估计没人做过 
model 模型 最好和数据库 中 一致 

------解决方案--------------------
验证分两类:

1是简单有效性验证:
比如注册的时候没有输入用户名,比如电话号码里面有个特殊符号,比如QQ号码里面带中文. 这些直接UI层验证就行了,虽然这也属于逻辑上的验证,但是这个逻辑是一个通用逻辑而不是该系统的逻辑,通用逻辑其实可以认为是一种常识性的逻辑判断,在任何一个层里都是需要常识的,所以放哪里都不会很影响整个系统的结构. 当然,肯定就放UI了.

2 另外是跟系统相关的验证:
比如用户已经存在了,要换个用户名,比如银行转账的金额超出系统允许金额,比如交易的时候余额不足,这些验证属于跟系统业务逻辑相关的验证,当然放在业务层更合理.

3 最后是跟业务逻辑并无必然联系但是数据库所需要的验证:
比如某个字段的输入长度超过字段长度(而且这个长度与业务逻辑无关),比如某个值为空(并且业务上允许其为空,但是具体使用的特定数据库不允许),比如同时显示几百张表的数据,对于SqlServer是无所谓,但是比如你用的是Sybase, 一句Sql语句只允许使用255张表 (虽然已经够大了,但是在动态生成语句的场合,不一定够用),等等,这些跟业务上也许没有关系,所以放业务层也怪怪,并且将来移植其他种类数据库也有问题, 可以丢在数据层验证. ------------当然,这个情况很少,因为一般总是跟业务有点关系的



model 层是实体类存放的位置,一般里面的类都是工具生成的,不要手动去编辑它. 但是也有些情况,给某个类加上一些方法能解决很多麻烦问题,比如给一个类实现一个ICloneable接口方便在很多地方应用原型模式. 这个时候在2.0以上版本里你可以使用一个局部类来写这个方法,强烈建议不要去修改那些工具生成的类(哪怕你现在是手工敲的代码,但是毕竟那是可以工具生成的,谁知道哪天你又用上某个工具了呢? 一更新你的代码就没了...)