Можно ли иметь два фреймворка в одном проекте? - PullRequest
3 голосов
/ 05 февраля 2009

Итак, я взял над веб-проектом Java . Приложение было написано другим разработчиком, который сейчас работает в другой компании. Вообще говоря, приложение простое, хорошо разработанное, и код достаточно документирован. Единственная проблема заключается в том, что предыдущий разработчик решил создать свою собственную библиотеку доступа к базе данных вместо использования популярного фреймворка. За годы своей карьеры программиста он создал впечатляющую структуру для доступа к любой базе данных (что-то похожее на облегченный Hiberbate).

Теперь у меня нет причин выбрасывать его код и заменять слой данных более обычным слоем JPA, поскольку текущий код работает просто отлично (хотя это заманчиво!). Но мне было интересно, стоит ли мне использовать более привычные рамки с новыми функциями. Стек приложений прост, и я легко могу подключить Hibernate или JPA. Таким образом, старые страницы (с новыми исправлениями) будут использовать старый фреймворк, а новая страница будет использовать новый фреймворк.

Однако одним из недостатков этого подхода является то, что он может запутать нового разработчика. Однако я также могу продолжать использовать старую платформу, расширяя / исправляя ее по мере необходимости. Как я уже сказал, это работает!

Ответы [ 6 ]

9 голосов
/ 05 февраля 2009

Вы, конечно, не хотите добавлять фреймворки по прихоти, но наоборот - плохо, когда пишете свою собственную псевдо-фреймворк, когда существует приемлемая альтернатива. В моей работе нам пришлось сделать преобразование из JPA в более JDBC-стиль, используя Spring. Во время преобразования я не удалял и не изменял ни один код JPA, я просто переписал его в JDBC. Как только мне станет удобно, что конкретный метод сработает, я поменяюсь реализацией. Это позволило мне постепенно перевести конверсию, не вытаскивая, так сказать, ковер из-под слоя обслуживания. Таким образом, чтобы полностью ответить на ваш вопрос, хорошо иметь 2 каркаса, если планируется переход на одну или другую.

4 голосов
/ 06 февраля 2009

Элдимо,

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

Если проект стабилен и находится на стадии сопровождения, вам не следует вносить радикальные изменения.

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

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

1 голос
/ 05 февраля 2009

Если это работает и впечатляет, зачем поддаваться искушению перейти на другую платформу без всякой причины? Если текущая структура не имеет каких-либо недостатков (трудно поддерживать, трудно понять, невозможно отладить и т. Д.), Я говорю, оставьте это в покое.

1 голос
/ 05 февраля 2009

В этом случае, я думаю, что ответ "да" .... , если , вы действительно можете использовать функции Hibernate или JPA, которыми обладает устаревшая библиотека, и если Вы уверены, что не сломаете ничего, что существует в настоящее время.

Включая либо Hibernate, либо JPA, вы не только снимаете с себя часть ответственности за обслуживание этих групп разработчиков, но, похоже, вы будете счастливее с точки зрения продвижения вперед.

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

1 голос
/ 05 февраля 2009

"это работает" - не трогай!

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

0 голосов
/ 05 февраля 2009

Настоящим недостатком подобных действий является риск того, что одна инфраструктура внесет изменения в базу данных, которые другая инфраструктура не сразу обнаружит. Я столкнулся с этим, прежде чем использовать комбинацию NHibernate + ADO.NET: если NHibernate что-то кэшировал, он может игнорировать изменения ADO.NET.

Если вы можете смягчить это, технически нет ничего плохого в этом.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...