Каково правильное количество абстракции от уровня данных?

Question

В настоящее время я разрабатываю структуру персистентности моего приложения ... и обсуждаю два решения для абстракции.

Вариант 1. Первый и более простой (но, возможно, более связанный сбаза данных представляет собой двухуровневый подход. В этом подходе средства отображения данных извлекают данные из базы данных и создают бизнес-объекты.

Примерная схема рабочего процесса:

UserEntity <= UserMapper => Database

Вариант 2. Второй, более гибкий (но возможный излишний) подход - это трехуровневый подход. В этом подходе у нас есть объект THIRD, задачей которого является исключительно обращение к базе данных и возврат массива данных в данные.Mapper, который затем создает объект.

Грубая диаграмма:

UserEntity <= UserMapper <= UserDataRetriever => Database

Очевидно, что преимущество первого варианта в том, что он проще и, следовательно, быстрее в создании. Преимущество второго варианта заключается в том, чточто мне проще изменить мои методы персистентности, поскольку мне нужно всего лишь изменить подключение моего DataRetriever к БД (и связанные запросы).

Поскольку размер этого сайта будет очень быстро увеличиваться в размере, я бы хотел выбрать наиболее гибкий вариант, не выходя на анти-шаблонную территорию.

Что лучше?

Answer 1

Я бы использовал следующее:

Entity <=> Repository pattern <=> DataSource

Хранилище будет выполнять сопоставление (или использовать слой сопоставления внутри).

Сам репозиторий может использовать vanilla ADO.NET и OR / M mapper, веб-сервис или что-то еще.

Answer 2

Ну, диаграмма для Варианта 2 будет немного более сложной:

UserEntity <= UserMapper <= UserDataEntity <= UserDataRetriever => Database

UserMapper придется отображать из одного типа в другой, следовательно, UserDataEntity,Концептуально неудобно отображать карту напрямую с UserDataRetriever до UserEntity.Возможно, вы подразумеваете следующую диаграмму для второго варианта:

UserEntity <= UserMapper <= [list of arrays] <= UserDataRetriever => Database

В любом случае, Опция 1 отличается здесь тем, что UserMapper включает в себя функциональность: [list of arrays]/UserDataEntity <= UserDataRetriever.

Ни один из вариантов по своей сути не лучше.Это зависит от количества объектов и от того, насколько легко отобразить постоянство и уровни домена.

Вместо этого вы можете попробовать Вариант 1.5 : ваш основной подход - Вариант 1. В то же время вы разрабатываете UserMapper, чтобы иметь отдельные и четко определенные методы для а) извлечения данных,и б) картографические данные.Таким образом, вы начнете худеть и сможете легко преобразовать эти методы в отдельные классы в будущем, если это необходимо.