Це одне й те саме? Щойно закінчив переглядати підручник Роберта Коннері з Storefront, і вони, схоже, схожі на техніку. Я маю на увазі, коли я реалізую об'єкт DAL, у мене є методи GetStuff, Add / Delete і т.д., і я завжди спочатку записую інтерфейс, щоб потім міг переключити db пізніше.
Я плутаю речі?
Відповіді:
Ти точно не той, хто плутає речі. :-)
Я думаю, що відповідь на запитання залежить від того, наскільки ви хочете бути пуристом.
Якщо ви хочете суворої точки зору DDD, це відведе вас на один шлях. Якщо ви подивитесь на сховище як на зразок, який допоміг нам стандартизувати інтерфейс шару, який розділяє між службами та базою даних, він зніме вас ще одним.
З моєї точки зору, сховище - це лише чітко визначений рівень доступу до даних. Інакше кажучи, це стандартизований спосіб реалізації вашого рівня доступу до даних. Існують деякі відмінності між різними реалізаціями сховища, але концепція однакова.
Деякі люди будуть розміщувати більше обмежень DDD на сховищі, а інші використовуватимуть сховище як зручний посередник між базою даних та рівнем обслуговування. Сховище, таке як DAL, ізолює сервісний рівень від особливостей доступу до даних.
Одне з питань впровадження, яке, схоже, робить їх різними, полягає в тому, що сховище часто створюється методами, які беруть специфікацію. Сховище поверне дані, які відповідають цій специфікації. Більшість традиційних DAL, які я бачив, матимуть більший набір методів, де метод прийме будь-яку кількість параметрів. Хоча це може здатися невеликою різницею, це велика проблема, коли ви входите в сфери Linq і Expressions. Наш інтерфейс сховища за замовчуванням виглядає так:
public interface IRepository : IDisposable
{
T[] GetAll<T>();
T[] GetAll<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter);
T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
void Delete<T>(T entity);
void Add<T>(T entity);
int SaveChanges();
DbTransaction BeginTransaction();
}Це DAL або сховище? У цьому випадку я здогадуюсь і того, і іншого.
Кім
Сховище - це шаблон, який можна застосовувати різними способами, тоді як рівень доступу до даних несе дуже чітку відповідальність: DAL повинен знати, як підключитися до вашого сховища даних для виконання CRUD-операцій.
Сховищем може бути DAL, але він також може розташовуватися перед DAL і виконувати роль моста між рівнем бізнес-об'єкта та рівнем даних. Яка реалізація використовується, залежить від проекту до проекту.
Одна велика різниця полягає в тому, що DAO - це загальний спосіб боротьби з наполегливістю для будь-якої організації у вашому домені. З іншого боку, сховище має справу лише з сукупними коренями.
Я шукав відповідь на подібне запитання і погоджувався з двома найвищими відповідями. Намагаючись уточнити це для себе, я виявив, що якщо Технічні характеристики, які йдуть рука об руку з шаблоном сховища, будуть реалізовані як першокласні члени доменної моделі, то я можу
Я навіть можу зайти так далеко і заявити, що, якщо шаблон репозиторію не використовується разом із специфікацією, це насправді не "сховище", а DAL. Надуманий приклад у псевдокоді:
specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)
assert that specification200.isSpecialCaseOf(specification100)
specificationAge = new AccountIsOlderThan('2000-01-01')
combinedSpec = new CompositeSpecification(
SpecificationOperator.And, specification200, specificationAge)
for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
assert that account.Created < '2000-01-01'
assert that account.Orders.Count > 200Докладніше дивіться у Есері специфікації Фоулера (саме на цьому я ґрунтувався вище).
DAL матиме спеціалізовані методи, як-от
IoCManager.InstanceFor<IAccountDAO>()
.GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')Ви бачите, як це може швидко стати громіздким, тим більше, що вам потрібно визначити кожен з інтерфейсів DAL / DAO за допомогою цього підходу та реалізувати метод запиту DAL.
У .NET, LINQ-запити можуть бути одним із способів впровадження специфікацій, але поєднання Специфікації (виразів) може бути не таким рівним, як у домашньому рішенні. Деякі ідеї для цього описані в цьому запитанні SO .
Моя особиста думка полягає в тому, що вся справа в картографуванні, див .: http://www.martinfowler.com/eaaCatalog/repository.html . Отже вихід / вхід із сховища - це об’єкти домену, які на DAL можуть бути будь-якими. Для мене це важливе доповнення / обмеження, оскільки ви можете додати реалізацію сховища для бази даних / служби / будь-якої іншої верстки, і у вас є чітке місце, щоб зосередитися на виконанні карти. Якщо ви не хочете використовувати це обмеження і мати відображення в іншому місці, тоді наявність різних способів представлення даних може вплинути на код там, де він не повинен змінюватися.
Перевага використання шаблону сховища полягає у знущанні над рівнем доступу до даних, щоб ви могли протестувати код бізнес-рівня, не викликаючи DAL-код. Є й інші великі переваги, але це, здається, дуже важливо для мене.
Як я розумію, вони можуть означати в основному те саме, але найменування змінюється залежно від контексту.
Наприклад, у вас може бути клас Dal / Dao, який реалізує інтерфейс IRepository.
Dal / Dao - термін рівня даних; вищі рівні вашої програми думають з точки зору сховищ.
Тож у більшості (простих) випадків DAO є реалізацією сховища?
Наскільки я розумію, здається, що DAO має справу саме з db-доступом (CRUD - не вибирає ?!), а сховище дозволяє абстрагувати весь доступ до даних, можливо, це фасад для декількох DAO (можливо, різних джерел даних).
Я на вірному шляху?
У зовнішньому світі (тобто клієнтському коді) сховище те саме, що і DAL, за винятком:
(1) для методів вставки / оновлення / видалення обмежено наявність об’єкта контейнера даних як параметр.
(2) для операції зчитування може знадобитися така проста специфікація, як DAL (наприклад, GetByPK) або розширена специфікація.
Внутрішньо він працює з шаром Mapper Data (наприклад, контекст структури сутності тощо) для виконання фактичної операції CRUD.
Що шаблон сховища не означає: -
Крім того, я бачив, що люди часто плутаються у тому, що вони мають окремий метод збереження як реалізацію зразка шаблону сховища, окрім методів Вставити / Оновити / Видалити, який фіксує всі зміни в пам'яті, виконані методами вставлення / оновлення / видалення до бази даних. Ми можемо мати метод збереження, безумовно, у сховищі, але це не є обов'язком репозиторію за виділення CUD-пам'яті в пам'яті (створення, оновлення, видалення) та методів збереження (що виконує фактичну операцію запису / зміни в базі даних), але відповідальність за підрозділ роботи.
Сподіваюся, це допомагає!
Можна стверджувати, що "сховище" - це специфічний клас, а "DAL" - це весь шар, що складається з сховищ, DTO, класів корисності та всього іншого, що потрібно.