1. لایه Data Access دارای یک Infrastructure است که فقط اینترفیسهای UnitOfWork و Repository در آن تعریف شده و هیچ خبری از IQueryable نیست مثلا برای دریافت داده صفحه بندی شده چیزی شبیه startRowIndex و maximumRows و حتی sortExpression پاس داده میشود.2. برای هر ORM یک پروژه جدا که به Data.Infrastructre رفرنس دارد ایجاد میشود. حالا در این پروژه UnitOfWork و Repository پیادهسازی میشود که از نظر داخلی به IQueryable وابسته است و مثلاً در پیادهسازی همان متد صفحه بندی شده به راحتی از LINQ استفاده میکند.3. هیچ کس حق ندارد در لایه های دیگر از IQueryable استفاه کند و باید ابتدا متد مورد نظرش را به Data.Infrastructure اضافه و بعد در لایه مرحله دو پیادهسازی کند.4. با استفاده از DI مسئله جایگذین کردن لایه مرحله 2 به راحتی اتفاق میافتد و هیچ لایهای مستقیم به پیادهسازی سمت Data وابسته نیست بلکه به Data.Infrastructure وابسته است.
من قبول دارم که این کار زمان بیشتری را میگیرد اما شما هم خوب میدانید که اگر میخواهیم وقت صرف کنیم و یک چهارچوب ماندگار ایجاد کنیم باید طراحی مستقل از تکنولوژی داشته باشیم (برای مثال حتی WPF و MVC که عرض کردم هم در چهارچوب جز Concrete class به حساب میآیند؛ هر چند از دید پروژه نهایی و مصرف کننده چهارچوب اینطور نیست).
مثال کاربردی این قضیه این است که در یک پروژه مجبور بودیم اطلاعات را رمزنگاری شده در DB ذخیره و بازیابی کنیم و البته فرم مورد نظر از هما CRUD های داخل چهارچوب بود و اگر این طراحی استفاه نمیشد مجبور بودیم برای آن یک فرم از یک ابتدا پیادهسازی کنیم و چون CRUD موجود در چهارچوب دارای امکانات قابل توجهی بود در زمان و هزینه تاثیر زیادی داشت.
[1] منظور از لایه، لایههای فیزیکی و سنتی نیست.