Это плохой дизайн? как это может быть улучшено?

Некоторое время назад я написал следующее, но недавно пришел посмотреть, и не думаю, что это хороший дизайн.

Конструкция предназначена для своего рода модульного уровня базы данных с использованием Entity Framework 4. Существует один объект базы данных, который (лениво) загружает контексты структуры объектов из внешних библиотек в указанном месте, а экземпляры загруженных контекстов хранятся в хеш-таблице для их имя (например, "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файл перекомпилируется, код генерируется заново, а любые добавления удаляются. Есть ли способ остановить это?

Как я могу улучшить этот дизайн? Что (еще) не так с этим? Или я на правильном пути?

Отказ от ответственности: я не использую Entity Framework и сильно склонен против любой вспомогательной структуры базы данных.

Похоже, вы сделали обертку.

Я делаю различие между «оберткой» и «слоем». Слой - это то, что вы можете скомпилировать в свою собственную DLL / project / Jar / что угодно. Уровень доступа к данным. Wrapper - это «вспомогательный» класс, который вы используете в этой DLL. С целью упрощения интерфейса или, возможно, устранения дублирования.

Проблема с упрощением интерфейса доступа к базе данных, как правило, не проста. Вы либо в конечном итоге дублируете интерфейс ADO / JDBC / и т.д. Или вы заставляете людей обойти это. Оболочки склонны делать всякие нежелательные вещи. Они могут автоматически закрывать соединение, когда вам нужно открыть его для поддержки транзакции. Они часто ошибочно оставляют соединения открытыми, если вам приходилось передавать данные, и используют один из этих языков для сбора мусора. Чтобы дать полную силу библиотеке за вашей оберткой, вы должны дублировать ее.

Такие библиотеки, как ADO / JDBC, уже являются БОЛЬШИМ интерфейсом. Это одни из лучших примеров ООП, сделанных правильно. Я бы предпочел использовать их поверх обертки, которую какой-то волшебник вытащил из своей шляпы.

Классический интерфейс в стиле JDBC / ADO хорошо известен и понят. Обертка, которую вы вытащили из вашей шляпы, не является.

Хотите уменьшить лишние «paramters.Add»? Посмотрите на дженерики. Или просто примите это, пытаясь уменьшить «paramter.Add», вы просто добавляете «.add» в другой слой кода.

Кстати, это отличный вопрос. Я бы проголосовал 10 раз, если бы мог.

Изменить: Конечно, код JDBC будет скрыт на уровне доступа к данным.