你要确认：所谓的三层架构UI+BLL+DAL，这个是相对的。就像C/S架构一样，所谓Client不过是需求方，Server则只是服务方，在典型的三层架构中，任何一个模块能对其它模块提供数据服务，那就是DAL，而任何一个模块需要别的模块提供数据服务，那就是UI，而作为某一个模块，假如它既需要别的模块提供数据，也能对另外的模块提供数据，那就是BLL。

当然，当我们说UI层的时候，我们总喜欢当作是能用可视元素表现出来才模块，而DAL则总喜欢当作是一个数据库或者是对数据库简单封装的DLL（如LINQ）。

所以，当我们提到三层架构的时候，不要把思路过于局限在某一个层面，认定三层中的表示层一定是UI，数据层一定是数据库。

WebService其实也是一个数据层的形式存在于使用它的应用中，而一个WebService又是一个独立的项目，它的表示层此时便是它所输出的数据结构（数据的表现形式）。

@笨笨蜗牛: 你现在应用的dal+bll+mvc中，三个层之间是如何传递数据的。是不是有一个额外的model层，并且这个层和数据库是对应的（codefirst中的model），这样的话，有一处地方的代码比较臃肿。当mvc的m和model层字段一样时，需要进行一次转化。

例如：

SchoolContext db = new SchoolContext();
var item=db.Students.ToList();//数据库数据列表
var list=new List<Student>();//此处的Student为mvc中的m
foreach( var q in item)
{
Models.Student model=new Models.Student();
model.ID=q.ID;
model.Name=q.Name;
list.add(model)
}
return View((list);

在如上代码示意中，当mvc的m和model不一致时还好说。（有些时候页面model和数据model不是完全对应的），但是当他们完全一致时，这样的代码就显得臃肿了。

有没有好的办法解决这个问题？

@快乐鸟: 对这个问题，倒没有什么有效的解决方案。

我一般会采取以下方式：

1——

重复的对属性进行调用：

如：

public class WebModel
{
    private BizModel _model;
    private BizModel Model
    {
        get
        {
            if(_model == null)
            {
                //create biz model
            }
            return _model;
        }
    }
    public object MyProperty
    {
        get
        {
            return Model.MyProperty;
        }
        set
        {
        }
    }
}

2——
使用反射的形式

3——

使用Dictionary或dynamic

4——

如果可能，采取继承的方式。

@笨笨蜗牛: 很多时候，我们在UI这个层次可能还有对数据进行进一步处理的需求，此时，则可以在Model里操作。

@笨笨蜗牛: 

方法1 的代码好像有问题。另外，其实这里把代码复杂化了，还不如我刚才实例的那样，直接去转化。

方法2和方法3哪里有介绍的？请简答说一下。

我总在想，有没有更好的办法避免这步？

@快乐鸟: 第二和第三不是很好的方案。我指的是根据某种需要或策略进行操作，要视具体情况。

至于更好的方法什么的，所有的一切都是有代价的，所谓得知桑榆失之东隅也就是这个道理。

ASP.NET MVC + Service + Repository 有基本示例吗？微软的看不懂

@快乐鸟: 如果上述两个项目你下载过，觉得有点难，你可以看DUDU给你推荐的。而且，在网上不可能找到符合你需求一模一样的项目，找个类似的，学习别人的设计思想，再针对自己的需求重新设计就行。还有就是dna和果园不是微软官方的项目。