All streams
Search
Write a publication
Pull to refresh
-9
0
serf @serf

User

Send message
Максимализмом тянет. От проблем с LazyInit часто не избавиться, с какого бы боку дынные не тянулись, у меня сложилось впечатление что вы мало работали с Hibernate и не совсем его понимаете. Допустим представьте что я хочу достать только саму сущность (в которой может быть очень много Lazy связей на другие сущности) без каких либо связей на другие сущности/таблицы, и сразу нарисовать его в XML, как тут можно контролировать логику? По мне так смысл этой статьи в существовании аннотации @XmlAccessorFactory, а LazyInit лишь пример ее использования.
За такие вещи тот кто «отзывает» оплату тоже теряет репутацию в банке, так что он еще подумает перед этим. Вряд ли банк захочет иметь дело с тем кто часто так делает. Но вам это не поможет конечно :)
Согласно статьи подход с DTO указал гугл.
В случае JAXB и одного представления всякие DTO избыточны, все разруливают аннотации, другое дело если одни и те же классы нужно представить по разному (разный формат XML), тут уже нужно немого думать как лучше сделать.
Я сейчас тоже заметил что кармы не хватает, слили поганцы за последнее время :)
Только исходник лучше по человечески куда залить (так и не добрался до него), хотя бы на pastebin.com, или github.
Довольно полезный материал, хорошая подача, спасибо, плюсую.
Считаете разумным учиться только на своих ошибках?
Наверно имелось ввиду что нужно больше действовать чем теоретизировать. Соглашусь.
Да я имел ввиду именно руководителя проекта, с техническими навыками, по другому, с прямым заказчиком-потребителем я пока что не работал.
Тогда скажите Java :)
Согласен, если то что не знаете это не более 30% задачи, то вполне можно браться. Только не нужно заявлять что вы эксперт в этой области, можно сказать имел некоторый опыт, имею представление. Я обычно не обманываю заказчиков, были случаи когда это окупалось.
В любом случае адекватный «новый» заказчик будет контролировать процесс. Будет требовать хотя бы раз в неделю отчеты о проделанной работе, возможно со скринами или с доступом к демо версии. «Старый» заказчик, с которым уже сложились доверительные отношения, вполне может ожидать сообщений только в случае возникновения каких-либо проблем, расхождений с договоренностями.
Это обязательно придет со временем
Иногда начинающим фрилансером становится разработчик отработавший на дядю 3-5+ лет, но все равно при этом он как бы начинающий фрилансер :)
Учитывайте что часто западные заказчики ценят честность и ответственность выше технических способностей.
В таком случае вероятно прежнее долгое сотрудничество устраивало обоих, и вряд заказчик станет кидать исполнителя, ведь найти и ввести в курс дела нового исполнителя будет затратно, я бы доверился :)
Хороший заказчик у вас, или это ваша стандартная практика со всеми заказчиками?
Но сомнения ведь в таких случаях всегда возникают, то есть риск осознанный, собственный выбор.

Information

Rating
Does not participate
Registered
Activity