Принципы ADO.net в Java

Question

Я спрашиваю мнение о реализации инфраструктуры, которая эмулирует ado.net в Java (таблицы данных, наборы данных и т. Д.). Идея состоит в том, чтобы избежать записи доменных объектов, поскольку они до сих пор просто используются для передачи данных с сервера на клиент и обратно, без каких-либо определенных бизнес-методов внутри них. Основная цель - ускорить время разработки. Могу ли я получить пользу от написания такого рода фреймворков? Если это сделано, прежде чем предоставить ссылку, пожалуйста.

Answer 1

Вместо эмуляции ADO.NET я бы использовал инструмент ORM , такой как Hibernate . Таким образом, вы можете иметь библиотеку, которая самостоятельно обрабатывает все ваши запросы SQL и персистентности, и вам не нужно беспокоиться о работе со структурой, подобной псевдотабличному.

Я считаю, что работать со строго типизированными объектами домена гораздо, намного проще и быстрее для разработки (и тестирования), чем работа с SQL, наборами результатов и т. Д.

Answer 2

Будь то ADO.NET или что-то еще, я узнал, что мой первый шаг должен состоять в том, чтобы не писать никаких библиотек или фреймворков. Вместо этого я продолжаю работу.

Во второй раз, когда я испытываю желание написать библиотеку или фреймворк, я обычно некоторое время думаю об этом, решаю не писать и продолжаю работу.

В третий раз, когда я испытываю искушение, я обычно поддаюсь искушению. К тому времени я напишу кучу кода, который работал без библиотеки или фреймворка. Я реорганизую этот код (реальный, использованный, проверенный код). Я буду делать это итеративно, постоянно выполняя свои автоматические модульные тесты и по мере необходимости писать новые тесты. Когда я прерываюсь в этой задаче (как это произойдет, так как написание фреймворков не может быть частью моей работы), я могу быть уверен, что оставляю выполнение кода позади, даже если он наполовину закончен.

Когда я вернусь к этому, я продолжу рефакторинг до определенного момента, помня, что мне нужно получить некоторый опыт, используя то, что я рефакторинг, прежде чем идти слишком далеко в направлении, которое я думаю должны идти. При использовании реального кода мне не нужно будет угадывать, в каком направлении проводить рефакторинг.