1

私はASP.NETMVCを初めて使用し、PHPMVCのバックグラウンドを持っています。それは一種の厄介な移行でした（私の質問の履歴を参照してください）。

理論上、.Netの世界で非常に気に入っているのは、モデルが永続性にとらわれないという考えです。しかし、この場合、モデルへの変更を保存する適切な方法は何ですか？$model->save();PHPでは、変換を行った後に呼び出すだけです。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（）の動作をモデルから独立させ、インターフェイスに抽象化する必要があります。

設計原則を覚えておいてください。実装ではなく、インターフェースに合わせて設計してください。

もう1つの注意点は、ピースを個別にテストする方法です。モデルがどのように永続化されるかを知らない場合は、モデルが何をすべきかに基づいてテストでき、永続化メカニズムはモデルが何をすべきかに基づいてテストできます。

いずれにせよ、Create（）アクションは2つの役割を果たしているように見えます。つまり、モデルを使用して保存し、次にDataAccessを使用して永続化しようとします。これらの2つのオブジェクトは同じことをしていますか？これは混乱を招いたり、後で読めなくなったり、保守できなくなったりする可能性がありますか？

于 2011-02-04T17:46:00.930 に答える