Це поганий дизайн? Як її можна вдосконалити?

Я написав наступне ще назад, але нещодавно прийшов переглянути його, і тепер не думаю, що це гарний дизайн.

Конструкція призначена для свого роду модульного рівня баз даних, що використовує Entity Framework 4. Існує єдиний об'єкт бази даних, який завантажує (ліниво) рамки контексту сутності з зовнішніх бібліотек у визначеному місці, а екземпляри завантажених контекстів зберігаються в хеш-таблиці проти їх назва (EG "ContentMgmtContext").

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

List<TReturn> Query<TReturn>(string Context, 
                             string Procedure, 
                             TransactionScope Scope, 
                             List<ObjectParameter> QueryParameters)

Ця модульність - це те, що мені подобається. Однак є один суттєвий недолік цього підходу: when using the database layer, the code using it has to have a reference to the library in which the context is stored, in order to access the types returned by the stored procedures through Entity Framework.у моделі об’єкти із шару бази даних переводяться на нові об’єкти, якими користуються представлення та контролер.

Я думаю, що це погана конструкція, але як я можу її вдосконалити? Я розглядав можливість додавання порожнього інтерфейсу, як IStoredProecedureObjectнадати кожному типу даних, що повертається збереженою процедурою, загальний базовий тип, однак, схоже, це було зірвано Entity Framework. Кожен раз, коли .edmxфайл перекомпілюється, код генерується заново, а будь-які доповнення видаляються. Чи є спосіб зупинити це?

Як я можу вдосконалити цей дизайн? Що (ще) з цим не так? Або я на правильному шляху?

Відмова від відповідальності: я не використовую фреймворк сутностей і сильно упереджений щодо майже будь-якої структури помічників бази даних.

Схоже, ви зробили обгортку.

Я розрізняю "обгортку" і "шар". Шар - це те, що ви можете скласти до власного DLL / проекту / Jar / що завгодно. Рівень доступу до даних. Wrapper, будучи класом "помічником", який ви використовуєте в цій DLL. З метою спрощення інтерфейсу або, можливо, усунення дублювання.

Проблема у спрощенні інтерфейсу доступу до бази даних - це, як правило, не просто. Ви або дублюєте інтерфейс ADO / JDBC / тощо. Або ви змушуєте людей обійти його. Обгортки, як правило, роблять всілякі непотрібні речі. Вони можуть автоматично закрити з'єднання, коли вам потрібно відкрити його для підтримки транзакції. Вони часто помилково залишають з'єднання відкритими, якщо вам довелося передавати дані та користуєтесь однією із цих зібраних сміттям мов. Щоб надати повну потужність бібліотеки за обгорткою, ви змушені її дублювати.

Бібліотеки типу ADO / JDBC - це вже ВЕЛИКИЙ інтерфейс. Вони є одними з найкращих прикладів OOP, зроблених правильно. Я вважаю за краще використовувати їх над обгорткою, яку витягнув капелюх із шапки.

Класичний інтерфейс стилю JDBC / ADO добре відомий і зрозумілий. Обгортка, яку ви витягнули з шапки, - це не.

Хочете зменшити зайві "параметри.Додати"? Погляньте на дженерики. Або просто прийміть, що намагаючись зменшити "paramter.Add", ви насправді просто натисніть ".add" на інший шар коду.

До речі, це чудове питання. Я б схвалив це 10 разів, якби міг.

Редагувати: Звичайно, код JDBC був би прихований у шарі доступу до даних.