Комментарии 6
Все это прекрасно работает до тех пор пока проект маленький и его просто поддерживать ввиду небольшого количества функционала. Интересно прочитать про то как удается придерживаться принципов SOLID в более приближенных к реальности условиях, типа дедлайнов, большого количества разрабов, работающих над одним проектом, нехватки квалифицированных кадров и отсутствия достаточного времени на ревью.
Особенно, когда проект вырастает стремительно. Вот еще «вчера» ты сидел в уютном проекте в одиночестве и все понимал, а вот уже у тебя в нем 10 разработчиков и проект вырос в четыре раза за 6 месяцев. Столкнулся недавно с такой проблемой. До сих пор разгребаем и выстраиваем работу.
Так solid как раз и помогает большим проектам, тк если это не так, то разгребание и понимание кода, а также его тестирование, превращается в боль
Про создание (D)TO- все надо делать обдуманно, не надо общих правил
https://stackoverflow.com/questions/21554977/should-services-always-return-dtos-or-can-they-also-return-domain-models
When not to Use
- Small to mid size project (5 members max)
- Project lifetime is 2 years or so.
- No separate team for GUI, backend, etc.
Arguments Against DTO
- Duplication of code.
- Cost of development time, debugging. (use DTO generation tools http://entitiestodtos.codeplex.com/)
- You must synchronize both models all the time.
- Cost of developement: Additional mapping is necessary. (use auto mappers like https://github.com/AutoMapper/AutoMapper)
- Why are Data Transfer Objects an anti-pattern?
Очень забавно читать про непринятие DI в контексте java разработки :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
10 самых распространенных ошибок Spring Framework