У нас есть несколько класссов модулей (около 80ти) . Все они делают некоторые запросы, читают данные из БД. И все они принимают ссылку на объект класса DAL, который содержит все методы доступа к БД. Итого около 400 методов.
Я хочу сделать следующий рефакторинг: для каждого модуля определить интерфейс, который будет содержать только необходимое подмножество методов из всего множества, содержащегося в классе DAL, и передавать уже его в модуль. Мне кажется, это позволит без изучения реализации модуля узнать, какие функции доступа к базе он использует. Сейчас этого сделать невозможно, потому что модуль получает ссылку на ДАЛ, в котором хранятся все методы.
Но вот беда: мои коллеги не поддерживают мое начинание
Они говорят, что нужно выделять лишние сущности — интерфейсы со списком методов, и надо следить, чтобы в классах доступа к данным небыло неиспользуемых в модулях методов.
К тому же они не видят проблемы в изучении реализации модуля для того, чтобы понять, какие запросы он делает к базе.
Какие еще аргументы за и против (технического плана, а не организационного) вы можете привести?
Кикие из приведенных аргументов кажутся неубедительными?
Здравствуйте, IT, Вы писали:
IT>Здравствуйте, Flem1234, Вы писали:
IT>Для начала спросите себя и своих коллег какие проблемы решают их ДАЛы и как ваши решения помогают их вам устранить.
У меня скорее другая ситуация: коллеги не видят проблемы в том, что каждый модуль принимает класс, в котором описаны все методы доступа к БД. Более того, они считают, что это полезно, потому что позволяет при написании модуля быстро узнавать, что такая функциональность уже есть и переиспользовать ее.
Короче, они себе представляют так:
Надо писать новый модуль:
Передал объект со всеми методами в модуль, поставил после него точку, выбрал из предложенных методов подходящий, если такого нет, то добавил в него (и в его интерфейс, и в его мок, потому что у нас есть мок для этого объекта для тестов) новый метод.
Надо фиксить или изменять старый: просмотрел реализацию модуля, нашел все методы, которые вызываются для нашего большого ДАЛ, поменял его, пофиксил мок, пофиксил интерфейс.
В случае мелких даллов, спроектированных для каждого модуля отдельно, не надо искать поиском по реализации модуля, а можно просто пофиксить интерфейс маленького дала и исправить то место, в котором ошибка была найдена компилятором. Плюс проще понимать код — изучив интерфейс для конкретного маленького дала, можно понять какие методя работы с БД он использует.
На это мне говорят, что реализацию модуля все равно надо изучать, потому что непонятно по сигнатуре метода, что он делает (хотя если настолько непонятно, как они собираются переиспользовать метод, который непонятно что делает) + что труднее поддерживать много интерфейсов, чем один интерфейс, хоть количество методов в них и равно.
У меня в большинстве случаев классы DAL — статические. Примерно по классу на каждую таблицу в БД (CustomerAccessor, OrderAccessor и т.д.). Тесты работают с реальной БД (так все устроено уже несколько лет) и меня это устраивает.
дробить dal на более мелкие части имеет смысл в случае распределенной среды Data Access Layer, как например в случае rest сервиса — когда есть ресурсо ориентированный сервис который может хоститься отдельно от другой части сервиса. плоскостей как можно поделить dal много- можно делить по компонентам или по интерфейсам или типу connection — ssl/tcp итд, особой пользы конечно от такого деления не будет если это не было заранее запланировано и оценено
400 методов это конечно бред, и надо рефакторить. Только я бы это делал не по используемым внутри модуля функциям — типа 1 интерфейс на 1 модуль, а сгруппировал бы методы в отдельные сервиса. Так, что-бы сервис работал с одной (или несколькими связанными) сущностями. Потом каждый модуль инжектит себе нужные сервиса через спринг, ejb или что у вас там используется. Так же обратите внимание, что если у вас очень много методов поиска скажем сущности AAA (с разыми фильтрами поиска), то можно порефакторить это собрав все фильтры поиска в отдельный класс AAASearchCriteria, тогда будет только один метод принимающий серч критерию.
Как убедить коллег? То что сейчас у вас есть — явно быдлокод. Сделайте нормально и почувствуете себя людьми. Потом дальше работать будет приятнее, новички не будут шарахаться и бежать из такого проекта. Есть у нас тоже один страшный проект где годами за кодом никто не следил. Так текучка там дай боже, т.к. новенькие не выдерживают треша.
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Здравствуйте, GreenTea, Вы писали:
GT>>400 методов это конечно бред, и надо рефакторить.
N_P>Иногда некуда У нас тут есть БД в 51 таблицу. Только CRUD к ней даст эти самые 400.
Хм, у нас таблиц почти столько же. 1 CRUD интерфейс для всех сущностей на 8 методов. Используем java/hibernate.
Здравствуйте, GreenTea, Вы писали:
N_P>>Иногда некуда У нас тут есть БД в 51 таблицу. Только CRUD к ней даст эти самые 400.
GT>Хм, у нас таблиц почти столько же. 1 CRUD интерфейс для всех сущностей на 8 методов. Используем java/hibernate.
А это как ? Я имею ввиду — реально методов, а не то, что только наружу как T Select<T> выставлено, а внутри кучу точных private вызывает.
Здравствуйте, ., Вы писали:
.>Вообще, странно почему pbf настолько нелюбим. Я вот помню тоже пытался это продвинуть, но все противятся, делая вот таких 400-методных монстров.
Ну мне, вот, например, с ходу не понятно — как там с взаимодействием. Типа 3 сущности апдейтятся с оглядкой друг на друга (порядок, ссылки)
Здравствуйте, Nikolay_P_I, Вы писали:
.>>Вообще, странно почему pbf настолько нелюбим. Я вот помню тоже пытался это продвинуть, но все противятся, делая вот таких 400-методных монстров. N_P>Ну мне, вот, например, с ходу не понятно — как там с взаимодействием. Типа 3 сущности апдейтятся с оглядкой друг на друга (порядок, ссылки)
Не понял. Пример покажи.
pbf это распределение классов во пакаджам (неймспейсам), и ничего более. Обычный SRP, но разделение идёт не по красивым словам DAO, DAL, Service, понятным только программистам, а по логике бизнес-области User, Order, Account.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Здравствуйте, GreenTea, Вы писали:
N_P>>>Иногда некуда У нас тут есть БД в 51 таблицу. Только CRUD к ней даст эти самые 400.
GT>>Хм, у нас таблиц почти столько же. 1 CRUD интерфейс для всех сущностей на 8 методов. Используем java/hibernate.
N_P>А это как ? Я имею ввиду — реально методов, а не то, что только наружу как T Select<T> выставлено, а внутри кучу точных private вызывает.
Вот что я имел в виду:
public interface IBaseDao extends IService
{
public <T extends IEntity> void save(T instance) throws EntityConstraintException;
public <T extends IEntity> void update(T instance) throws EntityConstraintException;
public <T extends IEntity> void delete(T instance);
public <T extends IEntity> void delete(Class<T> type, Long identifier);
public <T extends IEntity> T read(Class<T> type, Long identifier);
public <T extends IEntity> void saveOrUpdate(T instance) throws EntityConstraintException;
public <T extends IEntity> void refresh(T instance);
public <T extends IEntity> boolean isAttached(T instance);
}
Здравствуйте, GreenTea, Вы писали:
GT>Здравствуйте, Nikolay_P_I, Вы писали:
N_P>>Здравствуйте, GreenTea, Вы писали:
N_P>>>>Иногда некуда У нас тут есть БД в 51 таблицу. Только CRUD к ней даст эти самые 400.
GT>>>Хм, у нас таблиц почти столько же. 1 CRUD интерфейс для всех сущностей на 8 методов. Используем java/hibernate.
N_P>>А это как ? Я имею ввиду — реально методов, а не то, что только наружу как T Select<T> выставлено, а внутри кучу точных private вызывает.
Дошла суть вопроса.. Внутри тоже все примитивно
@Transactional
public class BaseDao extends AbstractDao implements IBaseDao
{
@Override
public <T extends IEntity> void save(T instance) throws EntityConstraintException
{
getCurrentSession().save(instance);
}
@Override
public <T extends IEntity> void update(T instance) throws EntityConstraintException
{
getCurrentSession().update(instance);
}
@Override
public <T extends IEntity> void delete(T instance)
{
if (null != instance) {
getCurrentSession().delete(instance);
}
}
public <T extends IEntity> void delete(Class<T> type, Long identifier)
{
delete(read(type, identifier));
}
@Override
public <T extends IEntity> void saveOrUpdate(T instance) throws EntityConstraintException
{
try {
getCurrentSession().saveOrUpdate(instance);
}
catch (HibernateException e) {
processConstraintException(e, instance);
throw e;
}
}
@Override
public <T extends IEntity> void refresh(T instance) {
getCurrentSession().refresh(instance);
}
public <T extends IEntity> boolean isAttached(T instance) {
return getCurrentSession().contains(instance);
}
private static void processConstraintException(HibernateException e, IEntity entity) throws EntityConstraintException {
if (e instanceof PropertyValueException) {
PropertyValueException z = (PropertyValueException)e;
throw new EntityConstraintException(z.getPropertyName(), null, entity);
}
else if (e instanceof ConstraintViolationException) {
throw new EntityConstraintException(null, null, entity);
}
}
}
Здравствуйте, Flem1234, Вы писали:
F>Но вот беда: мои коллеги не поддерживают мое начинание
Не понял чем твое начинание им мешает? Ты же просто предлагаешь оставить тот же объект DAL, но навешать на него по интерфейсу на каждый модуль? Соответственно коллеги смогут продолжать передавать весь объект DAL там где нужно/хочется.
F>Они говорят, что нужно выделять лишние сущности — интерфейсы со списком методов, и надо следить, чтобы в классах доступа к данным небыло неиспользуемых в модулях методов.
Так ты коллег хочешь нагрузить что ли созданием интерфейсов? Если твоя инициатива, то сам и делай. И затем новый код пиши уже с передачей интерфейса, а не конкретного типа DAL. Старый код поначалу можно вообще не трогать. Затем когда коллеги начнут понимать, что так действительно удобней можно уже и старый код на передачу интерфейсов перевести.
Здравствуйте, ., Вы писали:
.>>>Вообще, странно почему pbf настолько нелюбим. Я вот помню тоже пытался это продвинуть, но все противятся, делая вот таких 400-методных монстров. N_P>>Ну мне, вот, например, с ходу не понятно — как там с взаимодействием. Типа 3 сущности апдейтятся с оглядкой друг на друга (порядок, ссылки) .>Не понял. Пример покажи. .>pbf это распределение классов во пакаджам (неймспейсам), и ничего более. Обычный SRP, но разделение идёт не по красивым словам DAO, DAL, Service, понятным только программистам, а по логике бизнес-области User, Order, Account.
Например, при изменении TableOrder одновременно апдейтится TableOrderToUser (many-to-many) и логируются в TableJournal данные из TableAccount
DAL над ORM ? А почему не просто ORM ? И еще — почему вы считаете нормальным получать из DAL бизнес-логику, унаследованную от объектов ORM ? Я про IEntity ? Я не в смысле флейма, это именно вопрос Как оно на практике ? Работа, рефакторинг и прочее ? А что есть бизнес-логика не ложится на ORM и БД прямо, например, бизнес-объект — это совокупность 2,5 объектов ORM ?
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Здравствуйте, GreenTea, Вы писали:
N_P>DAL над ORM ? А почему не просто ORM ?
Не понял этого вопроса.
N_P>И еще — почему вы считаете нормальным получать из DAL бизнес-логику, унаследованную от объектов ORM ? Я про IEntity ? Я не в смысле флейма, это именно вопрос Как оно на практике ? Работа, рефакторинг и прочее ? А что есть бизнес-логика не ложится на ORM и БД прямо, например, бизнес-объект — это совокупность 2,5 объектов ORM ?
Не, у нас интерфейс IEntity наследуют все DTO (в вашей терминологии OMR) — простые обьекты переносчики данных, они без бизнес логики. Но есть так же BusinessObject-ы. Бизнес обьект это обертка над DTO-шкой и содержит логику по манипулции ее содержимым (логика эта может затрагивать несколько DTO, если у них нет своих бизнес обьектов). В бизнес обьекте могут быть другие бизнес обьекты, которым делегируется часть работы. Кстати, бизнес обьекты создаются спрингом, с вживленными зависимостями (бизнес обьектами, dao, инфраструктурыми сервисами). Но есть так же и бизнес сервиса, которые реализуют логику над группой бизнес обьектов, или производят поиск по критериям. Такой сервис, как правило, работает с одним юз кейсом, например "запись пациента на прием".
Здравствуйте, GreenTea, Вы писали:
GT>Здравствуйте, Nikolay_P_I, Вы писали:
N_P>>Здравствуйте, GreenTea, Вы писали:
Были кстати у нас раньше (та и сейчас где-то есть) сервиса посвященные одной сущности, выполняющие сложные разлинчые варианты поиска этой сущности. Но стараемся от этого уходить в сторону билдеров критерии. Эти билдеры — обертка над хибернетовской DetachedCriteria и предсотавляющие более высокоуровные методы добавления всяких условий поиска. И потом уже эти высокоуровневые билдеры критерий по многу раз используем в бизнес сервисах. Но как начальный вариант — сервис на сущность, мне кажется подойдет, для автора темы. + более высокоуровные бизнес сервиса. Все равно лучше чем 400 методов в одном сервисе
Здравствуйте, Nikolay_P_I, Вы писали:
N_P>Например, при изменении TableOrder одновременно апдейтится TableOrderToUser (many-to-many) и логируются в TableJournal данные из TableAccount
Как я понимаю это будет Service, т.к. бизнес-операция, а не DAO (доступ к бд).
Да и никто не мешает в один DAO-объект (OrderDaoImpl) заинжекитть другой (IJournalDao).
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Если нам не помогут, то мы тоже никого не пощадим.
У нас тут есть БД в 51 таблицу. Только CRUD к ней даст эти самые 400.
