Приложение по учету рабочего времени

Полезная. Не то слово. Оказываеться на работе я пол дня страдаю ерундой :) Насчет фреймворков - это делал именно на JDBC что бы понять идет работа с БД без фреймворков. Другой мини проект на SPRING+Hibernate+JavaFX. То же хочу выложить но сейчас красоту в нем навожу. Можете подробнее объяснить про вот этот абзац целиком: ------------ Так же, если говорить о JDBC, я бы подумал о вынесении общих частей логики в отдельный класс. Например у вас почти в каждом методе есть работа со Statement и resultset, почему бы не выделить это в отдельный сервис который принимал бы в себя кверю и возвращал готовый API объект? ------------------ не понял :( Поработайте над неймингом: Вот тут трудно. 10 лет с 1С и переложить именование к которому привык в Java не получается. Например есть Тип времени, а есть вид времени. Вид времени включает в себя тип времени(например Основная работа это работа и Подработка это работа) и хз как в английском это именовать. :((( MainLauncher.java И TimeTracker.java - это кастыли что бы java fx в jar запустить :(

Денис, а вы работаете разработчиком? Если да то можно вопрос, у меня в репозитории есть два проекта PriceDynamic и TimeTracker. Если не трудно, как Вы считаете, на позицию джуна эти пет проекты подойдут при собеседовании?

Так же, если говорить о JDBC, я бы подумал о вынесении общих частей логики в отдельный класс. Ну смотри, как бы приложение строил я. Тебе нужно работать с БД, значит есть смысл написать слой по работе с ней. Что-то, что будет непосредственно выполнять квери, возвращать результаты и так далее. Если у тебя будет такой слой, то не нужно будет копировать во все методы этот функционал. Ты грубо говоря вызовешь DBController.executeUpdateTime(query); где кверю ты уже будешь составлять в отдельном классе по работе с этим апдейт таймом. Точно так же и с остальным по аналогии. Как следствие, стоит подумать и о том, как организовать данные. Например вы говорите у вас есть условное Время, у него есть тип и вид (не совсем уловил разницу). Так почему бы не создать общую модель времени

class Time {
TimeType type;
TimeView view;
}

Заметь что и с геттерами сеттерами проще так. Time.getType , Time.getView Стоит отметить, что если оперировать тем же SpringData то вы могли бы создать такую Entity и из кода оперировать уже строго ей, не забивая себе голову кверями, а просто передав управление сущностью на соответствующие механизмы фреймворка (сохранение, получение, модификацию и пр). Для того их кстати и придумали ;) Но в целом конечно правильное построение архитектуры проекта штука замасловатая :) Это я сейчас идеями сыплю, а на самом деле главное что оно работает - это пожалуй основной критерий. Денис, а вы работаете разработчиком? как Вы считаете, на позицию джуна эти пет проекты подойдут при собеседовании? Да, работаю, а вот на сколько проекты тянут.... сложно сказать. Равно как и сложно сказать станут ли их читать те кому вы их пошлёте. Пет проекты это безусловно чудесно, они нужны и должны быть, но определяющим фактором, боюсь, не являются. Все будет зависеть от того как вы пройдете собес и возникнет ли химия между вами и теми кто вас собесит. Ну это самое значимое.

Больше спасибо за совет!

Большое спасибо :)