分层架构：UI、Entity和Repository

在明白了如何分层之后，我们就可以把我们的代码进行挪动，把他们放到合适的层里去了。

仍然以“注册”为例，我们梳理一下它包含的功能，各自应该放到哪一层：

UI层
应独立完成：
呈现页面，接收用户输入
验证用户输入是否有效（比如：不能为空，最小字符串长度等）
注册成功后跳转到“之前页面”

public class RegisterController:Controller
{
    public ActionResult Index(IndexModel model)
    {
        if (ModelState.IsValid)
        {
            //...
        }

        //...

        return Redirect("prepage");

注意：MVC是一种“架构”，但不是我们这里说的三层架构，Model View Controller都在UI一层当中。

早期的web开发（比如ASP/JSP/PHP）什么层都没有，就Html里面嵌套逻辑（和.cshtml里的代码块类似）就OK了，连接数据库啥的都可以写在这些代码块里……

此外，还需要依赖

Repository
完成：用户名是否重复。

    public ActionResult Index(IndexModel model)
    {
        //用户名是否已被使用
        UserRepository repository = new UserRepository();
        if (repository.GetByName(model.UserName) == null)
        {

我们已经大量的使用了各种Repository了，他们可以进行保存/读取/删除各种对象。

@想一想@：增删改查，和数据库交互……repository不是应该放在DAL层？

消失的DAL
因为EF等ORM工具的大量使用，很多同学会把Repoistory当做DAL使用。

@想一想@：为什么不应认为Repository是DAL？

注意：DAL返回的不能是BLL的对象

反证，如果Repository是DAL

它就应该由Entity调用……
它就不能返回Entity，因为只能是BLL引用DAL，不能DAL（Rrepository）引用BLL（Entity）啊！
实际上，Repository应该属于BLL。用ADO.NET可以更清楚的看出它应该如何调用DAL：

public User GetByName(string name)
{
    QueryHelper query = new QueryHelper();
    DbDataReader reader = query.GetBy(
        @"SELECT * FROM [User] WHERE [Name] = @name", 
        new SqlParameter("@name", name));

    User user = new User();
    reader.Read();
    user.UserName = reader["Name"].ToString();
    user.Password = reader["Password"].ToString();
    return user;
}

由此可见：

DAL返回的不能是BLL的对象，只能是DataReader/DataSet之类的数据库封装对象。
ORM超额完成了DAL的功能，^_^，更接近于Repository。复习：DbContext的注释说明
DbContext is a combination of the Unit Of Work and Repository patterns

Entity
需要被持久化（放到数据库）的类。

DTO和充血模式
DTO（Data Transfer Object）：用于数据传递的对象.

Entity肯定是DTO（将数据从BLL传到UI），但除此以外，它还能有其他作用么？

贫血模式：Entity就只能存储数据，所以只能有属性，不能有方法。
充血模式：Entity除了存储数据还应该实现业务逻辑，所以不光有属性，还要有方法。
我们选择主流的“充血”模式。

业务逻辑实现
比如，给新用户（掉落）随机数量的帮帮币：

public int BMoney { get; set; }
public void Register()
{
    BMoney += new Random().Next(10);
}

在Controller里面的调用代码如下所示：

User user = new User
{
    UserName = model.UserName,
    Password = model.Password,
};
user.Register();    //和数据库无关
repository.Add(user);

注意：Repository模式和Entity业务逻辑的配合，是体现BLL价值（面向对象）的关键。

如果将业务逻辑简化成数据库的UPDATE操作（或者更复杂的存储过程），就会形成“面向数据库”而不是“面向对象”的代码风格，BLL层也就没有存在的价值。

没有Repository
另外，因为Entity被Repository引用，所以Entity就不能再引用Repository（两个project之间不能相互引用）。

这给我们带来的好处是：

Entity不依赖于特定的持久化方式，即它既可以被SQL存储，也可以被Nosql存储（如果需要的话）
Entity能够方便的被单元测试
但是，也可能给我们的开发带来不便。（如何不便，一言难尽，碰到了就知道……简单的说，就是一个对象只能通过引用获得关联对象，无法获得通过Repository查询得到的对象）

所以，也有由Entity引用Repository，把Repository作为Entity集合使用的（不推荐）。

分层架构：UI、Entity和Repository

你可能感兴趣的:(javascript)