إذا كانت نماذجك محايدة للمثابرة، فكيف يمكنك حفظها؟

Question

أنا جديد على 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 Land، كانت وحدات التحكم الخاصة بي تصل إلى النماذج وطرق العرض فقط، بشكل أساسي.

Answer 1

ما تفعله جيد.ActiveRecord vs Repository vs Home Brew DAL هو سؤال أبدي سنناقشه إلى الأبد.

ال نمط المستودع يحظى بشعبية كبيرة في عالم .NET في الوقت الحالي ومن المحتمل أن ترى الكثير من الأمثلة على استخدامه.لا تهتم MVC باستراتيجية الوصول إلى البيانات الخاصة بك.إن استخدام أي شيء تجده مريحًا هو أمر جيد واستراتيجية أفضل من استخدام النمط لأن الجميع يفعلون ذلك.

Answer 2

من المقبول أن يحتوي النموذج على وظيفة Save()، لكنك عادةً تريد أن يكون سلوك Save() مستقلاً عن النموذج الخاص بك - مجردًا بعيدًا عن الواجهة.

تذكر مبادئ التصميم الخاصة بك:تصميم واجهة وليس تنفيذ

تحذير آخر هو كيف يمكنك اختبار القطع الخاصة بك بشكل فردي؟إذا كان النموذج لا يعرف كيفية استمراره، فيمكن اختباره بناءً على النموذج يجب افعل ذلك، ويمكن اختبار آلية استمرارك بناءً على ما تفعله يجب يفعل.

على أية حال، يبدو أن إجراء Create() الخاص بك يؤدي واجبًا مزدوجًا - حيث يحاول استخدام النموذج للحفظ، ثم يحاول استخدام DataAccess للاستمرار.هل هذين الكائنين يفعلان نفس الشيء؟هل يمكن أن يكون هذا مربكًا أو غير قابل للقراءة/غير قابل للصيانة لاحقًا؟