การสร้างเลเยอร์ของสิ่งที่เป็นนามธรรมเหนือเลเยอร์ ORM

ฉันเชื่อว่าถ้าคุณมีที่เก็บของคุณใช้ ORM ซึ่งมันมีนามธรรมเพียงพอจากฐานข้อมูล

อย่างไรก็ตามที่ที่ฉันทำงานอยู่ตอนนี้บางคนเชื่อว่าเราควรมีเลเยอร์ที่เป็นนามธรรม ORM ในกรณีที่เราต้องการเปลี่ยน ORM ในภายหลัง

มันจำเป็นจริงๆหรือเป็นเรื่องง่ายที่จะสร้างเลเยอร์ที่สามารถใช้งานกับ ORM จำนวนมากได้หรือไม่?

แก้ไข

เพียงเพื่อให้รายละเอียดเพิ่มเติม:

1. เรามีคลาส POCO และคลาสเอนทิตีที่แมปกับ AutoMapper คลาสเอนทิตีถูกใช้โดยเลเยอร์ Repository เลเยอร์ที่เก็บจากนั้นใช้เลเยอร์เพิ่มเติมของสิ่งที่เป็นนามธรรมเพื่อสื่อสารกับ Entity Framework
2. เลเยอร์ธุรกิจไม่มีทางเข้าถึงโดยตรงไปยัง Entity Framework แม้ว่าจะไม่มีเลเยอร์เพิ่มเติมของสิ่งที่เป็นนามธรรมเหนือ ORM สิ่งนี้จำเป็นต้องใช้เลเยอร์บริการที่ผู้ใช้เลเยอร์พื้นที่เก็บข้อมูล ในทั้งสองกรณีชั้นธุรกิจจะถูกแยกออกจาก ORM โดยสิ้นเชิง
3. อาร์กิวเมนต์หลักคือสามารถเปลี่ยน ORM ได้ในอนาคต เนื่องจากมันแปลเป็นภาษาท้องถิ่นภายในเลเยอร์ Repository สำหรับฉันมันแยกกันอยู่แล้วและฉันไม่เห็นว่าทำไมเลเยอร์ abstraction เพิ่มเติมจึงต้องมีรหัส "คุณภาพ"

วิธีนั้นก็คือความบ้าคลั่ง ไม่น่าเป็นไปได้สูงที่คุณจะต้องเปลี่ยน ORMs และถ้าคุณตัดสินใจเปลี่ยน ORM ค่าใช้จ่ายในการเขียนการแมปใหม่จะเป็นเพียงเศษเสี้ยวเล็กน้อยของต้นทุนในการพัฒนาและรักษา meta-ORM ของคุณเอง ฉันคาดหวังว่าคุณสามารถเขียนสคริปต์บางส่วนเพื่อทำงาน 95% ที่จำเป็นในการเปลี่ยน ORM

เฟรมเวิร์กในบ้านมักเป็นภัยพิบัติ การสร้างสิ่งที่คาดหวังความต้องการในอนาคตนั้นเกือบจะเป็นหายนะที่รับประกันได้ เฟรมเวิร์กที่ประสบความสำเร็จนั้นมาจากโครงการที่ประสบความสำเร็จซึ่งไม่ได้สร้างล่วงหน้าเพื่อตอบสนองความต้องการด้านจินตนาการ

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

อย่างน้อยที่สุดเลเยอร์ธุรกิจของคุณจำเป็นต้องตั้งโปรแกรมให้อินเทอร์เฟซที่ออบเจ็กต์ที่มีการจัดการ ORM ของคุณซึ่งเป็นตารางที่แมปจากชั้นข้อมูลสามารถนำไปใช้ได้ นอกจากนี้คุณอาจต้องสร้างเลเยอร์แบบอิงอินเตอร์เฟสของการสร้างคิวรีแบบนามธรรมเพื่อซ่อนความสามารถในการสอบถามดั้งเดิมของ ORM ของคุณ เป้าหมายหลักคือการหลีกเลี่ยงการ "อบใน" ORM เฉพาะใด ๆ ลงในโซลูชันของคุณนอกเหนือจากชั้นข้อมูล ตัวอย่างเช่นอาจเป็นการดึงดูดให้สร้างสตริงHQL ( Hibernate Query Language ) ในชั้นธุรกิจ อย่างไรก็ตามการตัดสินใจที่ไร้เดียงสาที่ดูเหมือนจะผูกชั้นธุรกิจของคุณกับไฮเบอร์เนตดังนั้นการตอกย้ำธุรกิจและชั้นการเข้าถึงข้อมูลด้วยกัน คุณควรพยายามหลีกเลี่ยงสถานการณ์นี้ให้มากที่สุด

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

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

UnitOfWork มักจะให้สิ่งที่เป็นนามธรรม เป็นที่ที่ต้องเปลี่ยนสถานที่เก็บของคุณขึ้นอยู่กับมันผ่านทางส่วนต่อประสาน หากคุณจำเป็นต้องเปลี่ยน O / RM เพียงใช้ UoW ใหม่เหนือสิ่งนั้น หนึ่งและทำ

BTW มันเป็นมากกว่าแค่การสลับ O / RM ให้คิดถึงการทดสอบหน่วย ฉันมีการใช้งาน UnitOfWork สามครั้งหนึ่งครั้งสำหรับ EF หนึ่งรายการสำหรับ NH (เพราะจริง ๆ แล้วฉันต้องสลับ O / RMs โครงการกลางสำหรับลูกค้าที่ต้องการการสนับสนุน Oracle) และหนึ่งในการคงอยู่ของ InMemory การคงอยู่ของ InMemory นั้นสมบูรณ์แบบสำหรับการทดสอบหน่วยหรือแม้แต่การทำต้นแบบอย่างรวดเร็วก่อนที่ฉันจะพร้อมที่จะวางฐานข้อมูลไว้ข้างหลัง

เฟรมเวิร์กนั้นใช้งานง่าย ก่อนอื่นคุณต้องมีอินเทอร์เฟซ IRepository ทั่วไป

public interface IRepository<T>
  where T:class
{
  IQueryable<T> FindBy(Expression<Func<T,Bool>>filter);
  IQueryable<T> GetAll();
  T FindSingle(Expression<Func<T,Bool>> filter);
  void Add(T item);
  void Remove(T item);

}

และส่วนต่อประสาน IUnitOfWork

public interface IUnitOfWork
{
   IQueryable<T> GetSet<T>();
   void Save();
   void Add<T>(T item) where T:class;
   void Remove<T>(T item) where T:class;
}

ถัดไปเป็นที่เก็บฐาน (ที่คุณเลือกว่าควรจะเป็นนามธรรมหรือไม่

public abstract class RepositoryBase<T>:IRepository<T>
  where T:class
{
   protected readonly IUnitOfWork _uow;

   protected RepositoryBase(IUnitOfWork uow)
   { 
      _uow=uow;
   }

   public IQueryable<T> FindBy(Expression<Func<T,Bool>>filter)
   {
      return _uow.GetSet<T>().Where(filter);
   }

   public IQueryable<T> GetAll()
   {
      return _uow.GetSet<T>();
   }

   public T FindSingle(Expression<Func<T,Bool>> filter)
   {
      return _uow.GetSet<T>().SingleOrDefault(filter);
   }

   public void Add(T item)
   {
      return _uow.Add(item);
   }

   public void Remove(T item)
   {
      return _uow.Remove(item);
   }
}

การใช้ IUnitOfWork คือการเล่นของเด็ก ๆ สำหรับ EF, NH และ In Memory เหตุผลที่ฉันส่งคืน IQueryable นั้นมีเหตุผลเดียวกัน Ayende ที่กล่าวถึงในโพสต์ของเขาลูกค้าสามารถกรองเรียงลำดับจัดกลุ่มและแม้แต่ฉายผลลัพธ์โดยใช้ LINQ และคุณยังได้รับประโยชน์จากการทำฝั่งเซิร์ฟเวอร์ทั้งหมด