วิธีการใช้รูปแบบพื้นที่เก็บข้อมูลอย่างถูกต้อง?

ฉันสงสัยว่าฉันควรจัดกลุ่มที่เก็บของฉันอย่างไร เช่นเดียวกับตัวอย่างที่ฉันเห็นใน asp.net mvc และในหนังสือของฉันโดยทั่วไปพวกเขาใช้ที่เก็บเดียวต่อตารางฐานข้อมูล แต่ดูเหมือนว่าจะมีที่เก็บมากมายที่ทำให้คุณต้องเรียกใช้ที่เก็บข้อมูลมากมายในภายหลังเพื่อล้อเลียนและสิ่งของต่างๆ

ดังนั้นฉันเดาว่าฉันควรจัดกลุ่ม อย่างไรก็ตามฉันไม่แน่ใจว่าจะจัดกลุ่มอย่างไร

ตอนนี้ฉันได้ทำการลงทะเบียน Repository เพื่อจัดการข้อมูลการลงทะเบียนทั้งหมดของฉัน อย่างไรก็ตามมี 4 ตารางที่ฉันต้องอัปเดตและก่อนที่ฉันจะมีที่เก็บ 3 แห่งเพื่อทำสิ่งนี้

ตัวอย่างเช่นหนึ่งในตารางคือตารางใบอนุญาต เมื่อพวกเขาลงทะเบียนฉันดูที่คีย์และตรวจสอบเพื่อดูว่ามีอยู่ในฐานข้อมูลหรือไม่ จะเกิดอะไรขึ้นถ้าฉันต้องการตรวจสอบรหัสใบอนุญาตนี้หรืออย่างอื่นจากตารางนั้นที่จุดอื่น ๆ จากนั้นลงทะเบียน

จุดหนึ่งสามารถล็อกอินได้ (ตรวจสอบว่าคีย์ยังไม่หมดอายุหรือไม่)

แล้วฉันจะทำอย่างไรในสถานการณ์นี้? เขียนโค้ดใหม่อีกครั้ง (แตก DRY)? พยายามรวม 2 ที่เก็บเหล่านี้เข้าด้วยกันและหวังว่าจะไม่มีวิธีใดที่จำเป็นในช่วงเวลาอื่น (เช่นบางทีฉันอาจมีวิธีที่ตรวจสอบว่ามีการใช้ userName หรือไม่ - บางทีฉันอาจจะต้องใช้ที่อื่น)

นอกจากนี้ถ้าฉันรวมเข้าด้วยกันฉันจะต้องใช้ชั้นบริการ 2 ชั้นที่ไปที่ที่เก็บเดียวกันเนื่องจากฉันคิดว่าการมีตรรกะทั้งหมดสำหรับ 2 ส่วนที่แตกต่างกันของไซต์จะยาวและฉันจะต้องมีชื่อเช่น ValidateLogin (), ValdiateRegistrationForm () , ValdiateLoginRetrievePassword () และอื่น ๆ

หรือเรียก Repository ก็ได้และมีชื่อที่ฟังดูแปลก ๆ ?

ดูเหมือนจะยากที่จะสร้างที่เก็บที่มีชื่อทั่วไปเพียงพอเพื่อให้คุณสามารถใช้กับหลาย ๆ จุดของแอปพลิเคชันของคุณและยังสมเหตุสมผลและฉันไม่คิดว่าการเรียกที่เก็บอื่นในที่เก็บจะเป็นแนวทางปฏิบัติที่ดี?

สิ่งหนึ่งที่ฉันทำผิดเมื่อเล่นกับรูปแบบที่เก็บ - เช่นเดียวกับคุณฉันคิดว่าตารางนั้นเกี่ยวข้องกับที่เก็บ 1: 1 เมื่อเราใช้กฎบางอย่างจากการออกแบบที่ขับเคลื่อนด้วยโดเมนปัญหาการจัดกลุ่มที่เก็บมักจะหายไป

Repository ควรเป็นต่อAggregate rootไม่ใช่ตาราง หมายความว่า - ถ้าเอนทิตีไม่ควรอยู่คนเดียว (กล่าวคือ - ถ้าคุณมีเอนทิตีRegistrantที่มีส่วนร่วมโดยเฉพาะRegistration) - เป็นเพียงเอนทิตีไม่จำเป็นต้องมีที่เก็บควรอัปเดต / สร้าง / ดึงข้อมูลผ่านที่เก็บของรูทรวม เป็นของ.

แน่นอน - ในหลาย ๆ กรณีเทคนิคการลดจำนวนที่เก็บนี้ (อันที่จริงมันเป็นเทคนิคในการจัดโครงสร้างแบบจำลองโดเมนของคุณมากกว่า) ไม่สามารถนำไปใช้ได้เนื่องจากทุกเอนทิตีควรเป็นรูทรวม (ซึ่งขึ้นอยู่กับโดเมนของคุณเป็นอย่างมาก ฉันสามารถเดาคนตาบอดเท่านั้น) ในตัวอย่างของคุณ - Licenseดูเหมือนจะเป็นรูทรวมเนื่องจากคุณต้องตรวจสอบได้โดยไม่มีบริบทของRegistrationเอนทิตี

แต่นั่นไม่ได้ จำกัด ให้เราใช้ที่เก็บแบบเรียงซ้อน (ที่Registrationเก็บได้รับอนุญาตให้อ้างอิงที่Licenseเก็บหากจำเป็น) นั่นไม่ได้ จำกัด ให้เราอ้างอิงที่Licenseเก็บ (ควรใช้ - ผ่าน IoC) โดยตรงจากRegistrationออบเจ็กต์

พยายามอย่าผลักดันการออกแบบของคุณผ่านความซับซ้อนที่มาจากเทคโนโลยีหรือการเข้าใจผิดบางอย่าง การจัดกลุ่มที่เก็บServiceXเพียงเพราะคุณไม่ต้องการสร้าง 2 ที่เก็บไม่ใช่ความคิดที่ดี

จะดีกว่ามากที่จะตั้งชื่อให้ถูกต้องRegistrationServiceนั่นคือ

แต่บริการที่ควรหลีกเลี่ยงในทั่วไป - พวกเขามักจะเป็นสาเหตุที่นำไปสู่รูปแบบโดเมนโรคโลหิตจาง

แก้ไข:
เริ่มใช้ IoC มันช่วยลดความเจ็บปวดจากการฉีดพึ่งพาได้อย่างแท้จริง
แทนที่จะเขียน:

var registrationService = new RegistrationService(new RegistrationRepository(),  
      new LicenseRepository(), new GodOnlyKnowsWhatElseThatServiceNeeds());

คุณจะสามารถเขียน:

var registrationService = IoC.Resolve<IRegistrationService>();

Ps จะดีกว่าถ้าใช้สิ่งที่เรียกว่าตัวระบุตำแหน่งบริการทั่วไปแต่นั่นเป็นเพียงตัวอย่างเท่านั้น

สิ่งหนึ่งที่ฉันเริ่มทำเพื่อแก้ไขปัญหานี้คือการพัฒนาบริการที่ห่อ N ที่เก็บ หวังว่าเฟรมเวิร์ก DI หรือ IoC ของคุณจะช่วยให้ง่ายขึ้น

public class ServiceImpl {
    public ServiceImpl(IRepo1 repo1, IRepo2 repo2...) { }
}

มันสมเหตุสมผลไหม นอกจากนี้ฉันเข้าใจว่าการพูดถึงบริการในคฤหาสน์นี้อาจหรืออาจไม่เป็นไปตามหลักการ DDD ฉันเพียงแค่ทำเพราะดูเหมือนว่าจะได้ผล

สิ่งที่ฉันกำลังทำคือฉันมีคลาสฐานนามธรรมที่กำหนดไว้ดังนี้:

public abstract class ReadOnlyRepository<T,V>
{
     V Find(T lookupKey);
}

public abstract class InsertRepository<T>
{
     void Add(T entityToSave);
}

public abstract class UpdateRepository<T,V>
{
     V Update(T entityToUpdate);
}

public abstract class DeleteRepository<T>
{
     void Delete(T entityToDelete);
}

จากนั้นคุณสามารถได้รับที่เก็บจากคลาสฐานนามธรรมและขยายที่เก็บเดียวของคุณตราบเท่าที่อาร์กิวเมนต์ทั่วไปแตกต่างกันเช่น

public class RegistrationRepository: ReadOnlyRepository<int, IRegistrationItem>,
                                     ReadOnlyRepository<string, IRegistrationItem> 

ฯลฯ ....

ฉันต้องการที่เก็บแยกต่างหากเนื่องจากเรามีข้อ จำกัด สำหรับที่เก็บบางส่วนของเราและสิ่งนี้ทำให้เรามีความยืดหยุ่นสูงสุด หวังว่านี่จะช่วยได้

ฉันมีสิ่งนี้เป็นคลาสพื้นที่เก็บข้อมูลของฉันและใช่ฉันขยายในที่เก็บตาราง / พื้นที่ แต่บางครั้งฉันก็ต้องทำลาย DRY

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MvcRepository
{
    public class Repository<T> : IRepository<T> where T : class
    {
        protected System.Data.Linq.DataContext _dataContextFactory;

        public IQueryable<T> All()
        {
            return GetTable.AsQueryable();
        }

        public IQueryable<T> FindAll(Func<T, bool> exp)
        {
            return GetTable.Where<T>(exp).AsQueryable();
        }

        public T Single(Func<T, bool> exp)
        {
            return GetTable.Single(exp);
        }

        public virtual void MarkForDeletion(T entity)
        {
            _dataContextFactory.GetTable<T>().DeleteOnSubmit(entity);
        }

        public virtual T CreateInstance()
        {
            T entity = Activator.CreateInstance<T>();
            GetTable.InsertOnSubmit(entity);
            return entity;
        }

        public void SaveAll()
        {
            _dataContextFactory.SubmitChanges();
        }

        public Repository(System.Data.Linq.DataContext dataContextFactory)
        {
            _dataContextFactory = dataContextFactory;
        }

        public System.Data.Linq.Table<T> GetTable
        {
            get { return _dataContextFactory.GetTable<T>(); }
        }

    }
}

แก้ไข

public class AdminRepository<T> : Repository<T> where T: class
{
    static AdminDataContext dc = new AdminDataContext(System.Configuration.ConfigurationManager.ConnectionStrings["MY_ConnectionString"].ConnectionString);

    public AdminRepository()
        : base( dc )
    {
    }

ฉันยังมี datacontext ซึ่งสร้างโดยใช้คลาส Linq2SQL.dbml

ตอนนี้ฉันมีที่เก็บมาตรฐานที่ใช้การเรียกมาตรฐานเช่น All และ Find และใน AdminRepository ของฉันฉันมีการเรียกเฉพาะ

ไม่ตอบคำถามเรื่อง DRY แม้ว่าฉันจะไม่คิดก็ตาม

นี่คือตัวอย่างของการใช้ Repository ทั่วไปโดยใช้ FluentNHibernate สามารถคงคลาสใดก็ได้ที่คุณเขียนแมปเปอร์ มันยังสามารถสร้างฐานข้อมูลของคุณโดยอิงจากคลาสผู้ทำแผนที่

รูปแบบ Repository เป็นรูปแบบการออกแบบที่ไม่ดี ฉันทำงานกับโปรเจ็กต์. Net เก่า ๆ มากมายและรูปแบบนี้มักทำให้เกิดข้อผิดพลาด "Distributed Transactions", "Partial Rollback" และ "Connection Pool Exhausted" ซึ่งสามารถหลีกเลี่ยงได้ ปัญหาคือรูปแบบพยายามจัดการการเชื่อมต่อและธุรกรรมภายใน แต่ควรจัดการที่เลเยอร์คอนโทรลเลอร์ นอกจากนี้ EntityFramework ยังสรุปตรรกะจำนวนมาก ฉันขอแนะนำให้ใช้รูปแบบบริการแทนเพื่อใช้รหัสที่แชร์ซ้ำ

ผมขอแนะนำให้คุณดูที่ชาร์ปสถาปัตยกรรม พวกเขาแนะนำให้ใช้ที่เก็บเดียวต่อเอนทิตี ฉันกำลังใช้มันอยู่ในโครงการของฉันและพอใจกับผลลัพธ์มาก