Причины за и против объектов, обращающихся с собственной настойчивостью

Question

Я смотрю на различные варианты моделирования персистентности в Windows Phone с использованием изолированного хранилища. Одна из идей, которые я выдвинул, заключалась в том, что каждый объект обрабатывает свое собственное (если оно имеет смысл, конечно) постоянство, а не создает хранилище или другой такой объект для сохранения объектов.

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

Кто-нибудь подходил к настойчивости таким образом? Если да, то что вы за или против в отношении этого подхода.

Answer 1

Существует несколько неоспоримых истин в разработке программного обеспечения:

1. Прототип становится продуктом, прежде чем вы его знаете.
2. Приложение, предназначенное "только для платформы-x", скоро будет перенесено на платформу-y.
3. Хранилище данных изменится. Вероятно, в результате # 2.

Есть еще (:)), но этого достаточно, чтобы ответить на ваш вопрос:

Пойдите с репозиторием, чтобы ваши объекты могли быть протестированы, ничего не знали о постоянстве, и вы могли поменять хранилища данных (даже по проводам!), А также спланировать это заранее.

Answer 2

Похоже, вы говорите о шаблоне Active Record ? Это работает для некоторых людей, но есть критика против этого (главным образом с точки зрения тестируемости / разделения проблем).

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

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

С другой стороны, это более простой шаблон, который люди могут понять, и это быстрый способ добиться успеха в легком проекте. Если количество классов невелико, то это может быть самый быстрый способ добраться от А до Б. Однако я все еще создаю отдельные репозитории для небольших проектов, но я просто не могу терпеть смешивание постоянных вещей с моей бизнес-логикой.

Answer 3

Минусы:

• Нарушение принципа единой ответственности (SRP)
• Снижает тестируемость
• Плотно связывает вашу бизнес-логику с базой данных

Плюсы:

• Простота реализации

В основном, если ваша модель данных плоская и простая, итребования к вашему приложению скромны, Active Record может быть хорошим выбором;однако, он начинает разрушаться, когда ваши требования к отображению становятся немного более сложными.В таких случаях подходят более надежные шаблоны ORM, такие как Data Mapper.

Answer 4

Плюсы

• простота

Против

• нарушает разделение интересов
• тесная связь бизнес-логики с базой данных
• делает тестирование намного сложнее

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

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

Если это простое приложение, вы, вероятно, можете отказаться от слоя DAL и перейти к более простой модели. Хотя, если в вашем приложении много движущихся частей и они имеют значительную сложность, я бы не стал удалять DAL, так как вы захотите хорошо тестировать и проверять свой код.

Answer 5

Это бросает вызов использованию уровня доступа к данным ... не то, чтобы с этим было что-то не так.