Пояснення шаблону сховища Покрокове пояснення [закрито]

276

Зачинено. Це питання поза темою . Наразі відповіді не приймаються.

Хочете вдосконалити це питання? Оновіть питання, щоб воно було тематичним для переповнення стека.

Закрито 7 років тому .

Може хтось, будь ласка, пояснить мені шаблон сховища в .NET, крок за кроком, наводячи дуже простий приклад або демонстрацію.

Я знаю, що це дуже поширене питання, але поки що я не знайшов задовільної відповіді.

c# asp.net design-patterns repository

— Са Патіль
джерело

msdn.microsoft.com/en-us/library/ff649690.aspx and codeproject.com/Tips/309753/…

— Maarten

Тут добре написано

— ssmith

Відповіді:

199

Як підсумок, я б описав ширший вплив структури сховища. Це дозволяє всім вашим кодом використовувати об'єкти, не знаючи, як об’єкти зберігаються. Усі знання про наполегливість, включаючи картографування від таблиць до об'єктів, безпечно містяться у сховищі.

Дуже часто ви знайдете SQL-запити, розкидані в кодовій базі, і коли ви приїдете додати стовпець до таблиці, вам доведеться шукати файли коду, щоб спробувати знайти звички таблиці. Вплив змін є далекосяжним.

За допомогою шаблону репозиторію вам потрібно буде змінити лише один об'єкт і одне сховище. Вплив дуже малий.

Можливо, це допоможе подумати над тим, чому б ви використовували шаблон сховища. Ось кілька причин:

У вас є єдине місце для внесення змін у доступ до ваших даних
У вас є одне місце, відповідальне за набір таблиць (як правило)
Замінити сховище на підроблену реалізацію для тестування легко - тому вам не потрібно мати доступну базу даних для ваших тестових модулів.

Є й інші переваги, наприклад, якщо ви використовували MySQL і хотіли перейти на SQL Server - але я ніколи цього не бачив на практиці!

— Фентон
джерело

Після переходу з dbms на b, я продовжу записувати, що я не тільки бачив це, я робив це у виробничому коді. Раніше ми використовували Oracle, мусили переключити хостинг-провайдера, оселившись на Azure (до того, як вони підтримали Oracle), тому нам довелося перейти на SQL Azure. На жаль, ми не розділили всю логіку доступу до даних на той момент, але ми, безумовно, це зробили так само, як і миграцію (і, продовжуючи, я можу додати).

— Джо

Я знаю, що цей коментар є старим і закритим, як поза темою, але я бачив це в багатьох компаніях. Як правило, це частина процесу переміщення до ORM або віддалення від нього. Сховище полегшує його вимкнення, особливо якщо ви завантажуєте їх із абстрактного заводського зразка або використовуєте контейнер IoC.

— Дерек Ван Куйк

Насправді сховище використовує DAO для своїх операцій, пов’язаних із джерелами даних ...

— Yousha Aleayoub

@YoushaAleayoub, що хороший бал ти піднімаєш. Ви, як правило, знайдете об'єкти доступу до даних, коли люди намагаються "розділити базу даних" і сховища, коли люди намагаються "зробити одну річ, відповідальну за запит". Майже у всіх випадках ви знайдете обоє разом. Частина DAO - це IConnectionта ICommandін. Частина, яка приховує тип бази даних. Зазвичай сховище більш орієнтоване на домен.

— Фентон

181

Це хороший приклад: Приклад шаблону сховища в C #

В основному, сховище приховує деталі того, як саме дані збираються / зберігаються з / до бази даних. Під обкладинками:

для читання він створює запит, що відповідає наданим критеріям, і повертає набір результатів
для написання він видає команди, необхідні для того, щоб основний механізм стійкості (наприклад, база даних SQL) зберігав дані

— двоколірний
джерело

Цей приклад - найкраще пояснення будь-коли, просто краще, ніж документація MSDN.

— Теоман шипахі

Я знайшов це дуже добре. Він також надає гідне пояснення щодо одиниці роботи, яка, здається, є більш загальною формою шаблону даних за шаблоном сховища

— Celdor

Зв'язаний приклад - збій шаблону сховища. Це взагалі не дає переваги порівняно з використанням інтерфейсів, що надаються Entity Framework ( IDbContext) або безпосередньо в nhibernate ( ISession). Правильно реалізований репозиторій відбирає ВСІ специфічні відомості щодо стійкості (наприклад, як працює поточний постачальник Linq To Sql). тобто ніколи не піддавати IQueryable.

— jgauffin

@jgauffin IQueryable- це не конкретна інформація щодо стійкості. Резервне копіювання IQueryable може бути таким же простим, як і жорстко закодований масив, або це може бути з файлу XML, веб-служби, бази даних, плоского файлу тощо. Я б не рекомендував сховище, яке не піддавало IQueryable, як завжди призводить до повільного доступу до даних у будь-якому випадку, коли викриття IQueryable дозволить деяким екземплярам покращити продуктивність, де це можливо, якщо збереження зберігає цю можливість. Крім того, приховування DbContext дозволяє вам перейти на інший ORM, якщо це потрібно (або немає ORM!)

— Роберт Маккі

Він просочується інформацією щодо постійної інформації. Спробуйте використовувати нетерплячий / ледачий завантаження або побудову INпропозиції sql, не знаючи, як це робить конкретний постачальник LinqToSql.

— jgauffin