ситуация: я проектирую задачу выделяю сущности: Продавец, Товар, Клиент, база уже существует и данные продавца хранятся например в таблице тех же клиентов но с типом продавец. какая то часть данных продавца например хранится в другой таблице доп.данные.
Во-первых. Разработка функционала усложняется тем что мне нужно орудовать не сущностными а с объектами базы данных и весь код будет завязан именно на логике работы с бд, начиная от названия таблиц которые могут не соответствовать наименованию разрабатываемого функционала заканчивая названия полей таблиц.
во-вторых смена хранилища, если я захочу получать товары не из бд а с сервиса, где свой формат хранения данных.
абстрагирование от бд позволяет делать гибче систему при дальнейших манипуляциях с источниками хранения данных.
Никаких сеттеров. Entity всегда дожна быть валидной - так то свойства загоняемые через конструкторы является обязательными и считается что без них модель не может существовать, а свойства изменяемые через сеттеры - необязательные. Если в модели 10-20 свойств, вы будете все через конструктор загонять?
Был случай, нашел фрилансера для разгрузки, он сделал пару задач, хорошо сделал. Через какое то время срочно нужна была его помощь но он видимо был занят другим проектом. Поэтому здесь не просто нужно собрать команду а важно ее удержать. А фрилансеры они такие сегодня здесь завтра там. Я думаю что нужна какая то система позволяющая организовывать работу фриланс групп (удавленников), позволяющая накапливать, прокачивать скиллы программистов, мотивируя работать именно в вашей группе с вашими проектами.
подождите а как же качество кода? есть проект, поставили задачу, фрилансер оценил, вы подтвердили, но в итоге он реализует таким способом что последующая поддержка код будет на нуле. Или допустим реализованный функционал начнет падать при высоких нагрузках кто будет его фиксить?
исключение должно быть при непредвиденной ситуации в системе, а получение категории либо получили либо нет - предвиденная, можно легко обработать, например вывести категории или если их нет то слово, нет категорий. Если вы все логику начнете шпиговать экзепшеннами то только все усложните.
Например я стал вашим клиентом, заказал у вас функционал,вы его сделали, получается при возникшей ошибке я звоню вам в любой момент и вы исправляете ее бесплатно, на период всей эксплуатации сайта, правильно я понял?
я не спорю зависит от типа сайта, за сайты визитки мы не беремся, в основном интернет магазины с приличными объемами данных, как правило использующие синхронизацию с 1С, там частенько идут обращения по этой теме. Если магазин не активно развивается , оборот не большой клиент как правило не оформляет поддержку, ему и обновления движка и модулей не нужный. Если клиент с большим оборотом, высокой активностью работы по модулям, то поддержка ему интересна, ведь еще и это бесплатное обновление системы и модулей.
Например я стал вашим клиентом, заказал у вас функционал,вы его сделали, получается при возникшей ошибке я звоню вам в любой момент и вы исправляете ее бесплатно, на период всей эксплуатации сайта, правильно я понял?
На счет доработки не спорю, но она не стабильна в плане финансов, сегодня ему нужно что то доработать, завтра он привлечет соседа программиста. Но имея тех поддержку можно спланировать свой бюджет, привлечь в помощь помощника, сформировать ему оклад, ты точно будешь уверен что в начало месяца поступят средства, а клиент будет уверен в том что ты в кратчайшие сроки исправишь ошибку на сайте, проконсультируешь, не кинешь, не будет ситуации что ты вдруг в отпуске или на больничном.
Но по большому счету даже тех поддержка имеет большее значение, это гарантия сотрудничества, я допустим не стал бы заниматься клиентом не имея тех поддержки с ним. Так как сделав функционал он тебя еще будет продолжительное время дергать по багам, вопросам и т.д., а это ведь время за которое тоже нужно платить.
