1

我是 ASP.NET MVC 的新手,来自 PHP MVC 背景。这是一种尴尬的过渡(请参阅我的问题历史,呵呵。)

在.Net 世界中,我在理论上非常喜欢的一件事是模型与持久性无关的想法。但是在这种情况下,将更改保存到模型的正确方法是什么?在 PHP 中,我只是$model->save();在进行一些转换后调用。在 C# 中,我不确定如何做到这一点。

这合适吗?

public class AwesomesauceController
{
    //inject!
    public AwesomeSauceController(IDataAccess da)
    {
        DataAccess = da;    
    }
    private readonly IDataAccess DataAccess;

    [HttpGet]
    public ActionResult Edit(int Id)
    {
        // PHP equiv: AwesomeSauceModel::find($id); Controller is unaware of DAL
        return View(DataAccess.AwesomeSauces.Where( sc => sc.Id == Id).FirstOrDefault());
    }

    [HttpPost]
    public ActionResult Edit(AwesomeSauce sc)
    {
        //persistence-aware version: model is aware of DAL, but controller is not
         if($sc->valid()
            $sc->save(); 
            redirect(); 
        }
        else { return view(); }

        // compare to persistence-agnostic version, controller is aware of DAL, but model is not
        if(ModelState.IsValid)
        {
            da.Persist(sc);
            return Redirect();
        }
        else
        {
            return View(sc);
        }
    }
}

我想唯一让我觉得错误的是,通常情况下,我不希望控制器以这种方式直接访问数据访问层。以前,在 PHP 领域,我的控制器基本上只能访问模型和视图。

4

2 回答 2

2

你在做什么很好。ActiveRecord vs Repository vs Home Brew DAL 是一个永恒的问题,我们将永远讨论。

存储库模式现在在 .NET 世界中非常流行,您可能会看到很多使用它的示例。MVC 并不关心你的数据访问策略是什么。使用你觉得舒服的任何东西都很好,并且比使用模式更好,因为其他人都在这样做。

于 2011-02-04T18:09:42.323 回答
1

模型具有 Save() 函数是可以的,但您通常希望 Save() 行为独立于您的模型——抽象为接口。

记住你的设计原则:设计一个接口,而不是一个实现。

另一个警告是你如何单独测试你的作品?如果一个模型不知道它是如何持久化的,那么可以根据模型该做什么来测试它,而你的持久化机制可以根据它该做什么来测试。

在任何情况下,您的 Create() 操作似乎都在执行双重任务——尝试使用模型进行保存,然后尝试使用 DataAccess 进行持久化。这两个对象做同样的事情吗?这会在以后造成混淆或不可读/不可维护吗?

于 2011-02-04T17:46:00.930 回答