分层构架系统有时候就是＂鸡肋＂，这里举个明显的例子
大家好，我是新手，水平有限，说错了的地方大家批评指正，谢谢！最近做个三层构架的商城，在做广告维护模块时候更新的内容涉及到图片和文字，更新大概分：
１．图片文字都更新
２．图片更新，文字不更新
３．图片不更新，文字更新．
鸡肋就在第三种情况，下面系统的ＭＯＤＥＬ
  public   class   Advertsement
        {
                public   Advertsement()
                {

                }

private   int   _adid;
private   string   _adinfo;
private   string   _adpic;
private   string   _adurl;
///   <summary>
///  
///   </summary>
public   int   AdId
{
set{   _adid=value;}
get{return   _adid;}
}
///   <summary>
///  
///   </summary>
public   string   Adinfo
{
set{   _adinfo=value;}
get{return   _adinfo;}
}
///   <summary>
///  
///   </summary>
public   string   AdPic
{
set{   _adpic=value;}
get{return   _adpic;}
}
///   <summary>
///  
///   </summary>
public   string   AdUrl
{
set{   _adurl=value;}
get{return   _adurl;}
                }
               
　图片的更新用到控件FileUpload，当不需要更新图片时候FileUpload内容为空
　但是这时的更新Model类里面也得有个AdPic，所以只好另外写个获取的函数获取到数据库中原来的AdPic来给Model类中的AdPic   赋值，如果不用三层用if   (this   .FileUploadId   .HasFile)   分情况写ＳＱＬ语句就可以了，感觉还来的灵活些，大家说分层绕来绕去是不是性能更低啊？

------解决方案--------------------
up
------解决方案--------------------
o
------解决方案--------------------
感觉是你的模型或数据层没写好

如果你的目的是性能，自然是直接SQL最好，但分层的目的是关注分离，好维护，可重用性好。。。如果你不在乎这些东西的话，大可直接使用SQL

------解决方案--------------------
up
------解决方案--------------------
似乎思归说的对，但个人不同意，作程序不能一边倒的，什么事都讲个“和谐”，讲个“平衡”
------解决方案--------------------
//需求一直在变，保持关注分离

在做n层维护的时候也有悖论，尤其是当数据库结构变化的时候，model和dal层都会有变化，这

样的耦合度在增加

我现在用部分类，依然使用代码生成器（codesmith）似乎自己做的模版还成，减少代码生成器

生成的代码和自己手写的代码的耦合
------解决方案--------------------
同意思归的看法。关注分离，否则项目一大，到了后期维护的时候才知道什么是后患无穷，我们早已深受其害
------解决方案--------------------
LZ没有理解多层的含义;

多层的时候,会导致开发量以及成本的增加和开发周期的延长,但是它的优点在于规范性,可维护扩充性,重用性.

有利必有鄙,所以要根据情况来选择,不是一味的追求一个定式.在大型应用项目和成熟团队中,牺牲效率来换取规范和可维护性显的更加重要~
------解决方案--------------------
楼主知识体系的不完整导致会出现这种想法……

希望楼主再过两年再回头来看这个问题，到时候也许就会觉得当初为什么会问那么白痴的问题了。
------解决方案--------------------
架构设计的不合理..
或者架构设计师是个不懂编码的架构设计师..
------解决方案--------------------
N-Tiers 又不是万能膏药，怎能到处贴，特别是不痛不痒的 ....
------解决方案--------------------
多层的目的是规范，重用，对性能没有什么太大的优化。如果不需要重用，也不需要和其他人协同工作，怎么写都随意了。