ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Архитектура DAO
43 сообщений из 43, показаны все 2 страниц
  все  
Архитектура DAO
    #39381619
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
Подскажите пожалуйста, делаю простое приложение для работы с БД.
Таблица Работник(id,имя,фамилия, должность, филиал)
Таблица филиал(id,филиал)
Таблица должность(id,должность)

Модель соответственно:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
class Employee{
 private Integer id;
 private String firstName;
 private String lastName;
 private Position position;
 private Branch branch;

//getter and setter
}

...



Есть интерфейс EmployeeDao и реализация этого интерфейса.
Вопрос вот в методе findAll я делаю простой запрос
Код: plsql
1.
SELECT * FROM Работник



И получаю соответственно

1 Вася Пупкин 1 1

Чтобы вывести непосредственно значения из других таблиц по id как правильно это реализовать?

Я вижу два варианта делать отдельно DAO для должности, филиала и в DAO работника держать объекты их.
Или сделать просто сложный запрос?
...
Рейтинг: 0 / 0
10.01.2017, 16:00
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39381649
Фотография -=Koba=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-=Koba=-
Участник
Связать
Работника с Филиалом и Должность в Enity
@OneToMany
...
Рейтинг: 0 / 0
10.01.2017, 16:20
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39381659
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
-=Koba=-,

через JDBC делаю
...
Рейтинг: 0 / 0
10.01.2017, 16:25
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39381695
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
slavik_mscИли сделать просто сложный запрос?
делать под VIEW.
Если простой просмотр на страничке, то
Код: java
1.
2.
select id, name, должность from USER
JOIN Должности
...
Рейтинг: 0 / 0
10.01.2017, 17:10
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39381699
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
slavik_msc-=Koba=-,

через JDBC делаю
Очень зря. Spring Data + JPA сильно упростят код.
...
Рейтинг: 0 / 0
10.01.2017, 17:13
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39381700
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
BlazkowiczОчень зря. Spring Data + JPA сильно упростят код.

Согласен, делаю в качестве обучения, Spring контейнер использую.
Цель сделать сначала через JDBC, потом подтянуть ORM
...
Рейтинг: 0 / 0
10.01.2017, 17:14
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39381981
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
mad_nazgul
Участник
slavik_mscBlazkowiczОчень зря. Spring Data + JPA сильно упростят код.

Согласен, делаю в качестве обучения, Spring контейнер использую.
Цель сделать сначала через JDBC, потом подтянуть ORM

Если ч/з JDBC, то создаете нужный вам запрос, который кладете в POJO класс.
Т.е. как бы проблемы совсем нет.
Главное знать SQL.
После того, как научитесь писать запросы ORM покажется вам смирительной рубашкой. :-)

А так:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
select работник.id,
работник.имя,
работник.фамилия,
филиал.филиал,
должность.длжность
from работник
left join филиал on филиал.id = работник.филиал
left join должность on должность.id = работник.должность


Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
class Employee{
 private Integer id;
 private String firstName;
 private String lastName;
 private String position;
 private String branch;

//getter and setter
}
...
Рейтинг: 0 / 0
11.01.2017, 07:38
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382068
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
mad_nazgul,
Спасибо, по делу всё.

Коллеги, подскажите еще момент.
Правильно ли я понимаю можно использовать два подхода
1) JDBC, здесь всю логику отдаём запросам, и классы будут простые
2) JPA, здесь вся логика уходит на классы, маппируем классы на таблицы, и вся основная работа с объектами java происходит
...
Рейтинг: 0 / 0
11.01.2017, 10:35
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382078
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
slavik_mscПравильно ли я понимаю можно использовать два подхода
1) JDBC, здесь всю логику отдаём запросам, и классы будут простые
2) JPA, здесь вся логика уходит на классы, маппируем классы на таблицы, и вся основная работа с объектами java происходит
Нет. JDBC это просто интерфейс работы с БД. Он не диктует где именно вы держите логику, в Java или в БД. Если уж держать логику в БД, то точно не в SQL запросах, запускаемых JDBC, а в хранимых процедурах и функциях, на языке который плохо масштабируется и крайне ограничен.

Вы бы это. Фаулера что ли почитали. Enterprise Patterns. Масса подобных вопросов отпала бы.
...
Рейтинг: 0 / 0
11.01.2017, 10:42
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382089
Basil A. Sidorov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Basil A. Sidorov
Участник
BlazkowiczЕсли уж держать логику в БД, то точно не в SQL запросах, запускаемых JDBC, а в хранимых процедурах и функциях, на языке который плохо масштабируется и крайне ограничен.... в неумелых и/или кривых руках.
Не могут встроенные возможности СУБД масштабироваться хуже или лучше самой СУБД.
...
Рейтинг: 0 / 0
11.01.2017, 10:52
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382093
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
BlazkowiczВы бы это. Фаулера что ли почитали. Enterprise Patterns. Масса подобных вопросов отпала бы.

Спасибо за рекомендацию, обязательно займусь, потому что с пониманием архитектуры есть большие проблемы.
...
Рейтинг: 0 / 0
11.01.2017, 11:00
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382095
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Basil A. Sidorovв неумелых и/или кривых руках.
Не могут встроенные возможности СУБД масштабироваться хуже или лучше самой СУБД.
Масштабирование данных и выборки и масштабирование рантайма это совсем разные вещи.
...
Рейтинг: 0 / 0
11.01.2017, 11:02
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382096
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
Blazkowicz,

т.е. как посоветовал mad_nazgul это неверно?
...
Рейтинг: 0 / 0
11.01.2017, 11:03
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382099
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
slavik_mscт.е. как посоветовал mad_nazgul это неверно?
Что именно там не верно?
...
Рейтинг: 0 / 0
11.01.2017, 11:08
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382104
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
Basil A. Sidorov... в неумелых и/или кривых руках.
Не могут встроенные возможности СУБД масштабироваться хуже или лучше самой СУБД.
Могут. Не всякая СУБД позволяет во встроенном процедурном ЯП устраивать многопоточные вычисления. А уж о механизме кеширования/инвалидации результатов запросов использующих вызовы определенных пользователем функций обрабатывающие данные внутри СУБД можно забыть почти сразу. Часто использование не SQL ЯП требует еще и дополнительных накладных расходов. Причем часто для доступа к данным из такого ЯП нужно опять задействовать SQL.
В общем далеко не серебрянная пуля.
...
Рейтинг: 0 / 0
11.01.2017, 11:14
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382127
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
BlazkowiczЧто именно там не верно?

Что один класс вместо трех.
И запросом всё пихаем в один.
...
Рейтинг: 0 / 0
11.01.2017, 11:32
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382135
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
mad_nazgulА так:
А мне последнее время нравится такое DAO
Код: java
1.
private HashMap<String,Object> values


ну и геттеры и сеттеры. :)
плюс универсальный метод чтения (из RowSet)-записи в БД.
...
Рейтинг: 0 / 0
11.01.2017, 11:39
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382140
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
slavik_mscBlazkowiczЧто именно там не верно?

Что один класс вместо трех.
И запросом всё пихаем в один.
Аа. Не заметил сразу. Да. Это не верно. Нет смысла ломать свои бизнес-объекты. Никто не мешает результаты одного запроса разложить по дереву объектов.

Запросы это такая штука, которая подвержена изменениям с ростом БД из-за необходимости оптимизаций. Шанс что запрос нужно будет менять - очень велик. Но не будем же мы перепиливать всю модель предметной области из-за этого. Просто модель будет конструироваться иначе.

Современные ORM эту проблему решают очень элегантно. Хотим JOIN - получаем JOIN. Хотим несколько SELECT - так и указываем при выборке. Нет необходимости ни менять модель, ни переписывать запросы.
...
Рейтинг: 0 / 0
11.01.2017, 11:44
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382141
am_sasa
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
am_sasa
Гость
Сергей Арсеньев
Код: java
1.
private HashMap<String,Object> values


ну и геттеры и сеттеры. :)
плюс универсальный метод чтения (из RowSet)-записи в БД.
Точно, люто плюсую, т.к. я это делаю уже лет этак 5+
...
Рейтинг: 0 / 0
11.01.2017, 11:45
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382162
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Сергей Арсеньевmad_nazgulА так:
А мне последнее время нравится такое DAO
Код: java
1.
private HashMap<String,Object> values


ну и геттеры и сеттеры. :)
плюс универсальный метод чтения (из RowSet)-записи в БД.
Это не DAO. Идея хранить данные в мапах не нова. Но про комбинацию со строго типизироваными свойствами я ещё не слышал. Любопытно было бы посмотреть.
Самая большая проблема тут (ИМХО) в том что подобная модель будет совершенно анемичной. Писать логику на Map совсем грустно. Соответсвтенно вы её будете писать снаружи, нарушая инкапсуляцию.
Есть и несколько проблем поменьше - это рефакторинг и перенос ряда ошибок из compile time в run time.

Интересно было бы посмотреть на то как происходит работа с ассоциациями. В том числе при апдейтах.
...
Рейтинг: 0 / 0
11.01.2017, 12:02
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382174
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
Blazkowicz,

т.е. правильно ли я понимаю:
у меня три класса:
Код: java
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
class Employee{
 private Integer id;
 private String firstName;
 private String lastName;
 private Position position;
 private Branch branch;

//getter and setter
}

class Position{
 private Integer id;
 private String position;

//getter and setter
}

class Branch{
 private Integer id;
 private String branch;

//getter and setter
}



Запрос будет такой же как и предложил mad_nazgul но добавятся в выборке position.id , branch.id

и уже в RowMapper я создаю три объекта Branch , Position , Employee и заполняю полями из запроса.

Так я понимаю?
...
Рейтинг: 0 / 0
11.01.2017, 12:13
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382180
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
slavik_mscТак я понимаю?
Да. А про jOOQ читали?
...
Рейтинг: 0 / 0
11.01.2017, 12:16
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382182
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
BlazkowiczДа. А про jOOQ читали?

К сожалению нет, сейчас почитаю, Спасибо вам большое.
...
Рейтинг: 0 / 0
11.01.2017, 12:21
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382205
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
Blazkowiczslavik_mscТак я понимаю?
Да. А про jOOQ читали?

А вам хватает бесплатной версии или вы использовали профешнл?
...
Рейтинг: 0 / 0
11.01.2017, 12:41
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382207
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
BlazkowiczЭто не DAO. Идея хранить данные в мапах не нова. Но про комбинацию со строго типизироваными свойствами я ещё не слышал. Любопытно было бы посмотреть.
Самая большая проблема тут (ИМХО) в том что подобная модель будет совершенно анемичной. Писать логику на Map совсем грустно. Соответсвтенно вы её будете писать снаружи, нарушая инкапсуляцию.
Есть и несколько проблем поменьше - это рефакторинг и перенос ряда ошибок из compile time в run time.

Интересно было бы посмотреть на то как происходит работа с ассоциациями. В том числе при апдейтах.

+100500. Уж лучше ActiveRecord в таком случае. Зачем нужен строготипизированный язык если всю логику писать на мапах?
...
Рейтинг: 0 / 0
11.01.2017, 12:43
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382208
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
BlazkowiczПисать логику на Map совсем грустно.
Все зависит от задачи. Построить на экране табличку на мапе - 1 цикл.
Сделать ее динамической по настройкам - плевое дело.
Добавить поле - даже в код лезть не надо.
и т.п.

Все тоже самое на геттерах-сеттерах - чистой воды чайна-код.
...
Рейтинг: 0 / 0
11.01.2017, 12:43
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382211
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
Сергей АрсеньевBlazkowiczПисать логику на Map совсем грустно.
Все зависит от задачи. Построить на экране табличку на мапе - 1 цикл.
Сделать ее динамической по настройкам - плевое дело.
Добавить поле - даже в код лезть не надо.
и т.п.

Все тоже самое на геттерах-сеттерах - чистой воды чайна-код.

А потом бац и надо поменять customerId(long) на customerUUID(String) :)
...
Рейтинг: 0 / 0
11.01.2017, 12:45
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382229
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
забыл никА вам хватает бесплатной версии или вы использовали профешнл?
Пользовал QueryDSL, там где лицензии jOOQ не хватало. jOOQ круче. Но, в целом, не моё. Просто был legacy проект с корявым дизайном БД, там ORM был совсем не к месту.
Для нормальных ERP систем Hibernate всё ещё рулит.
...
Рейтинг: 0 / 0
11.01.2017, 13:00
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382231
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
забыл ник+100500. Уж лучше ActiveRecord в таком случае. Зачем нужен строготипизированный язык если всю логику писать на мапах?
Зависит от подхода, но у меня такая же мысль была. Проще взять любой язык без строгой типизации.
...
Рейтинг: 0 / 0
11.01.2017, 13:01
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382234
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Сергей АрсеньевВсе зависит от задачи. Построить на экране табличку на мапе - 1 цикл.
Сделать ее динамической по настройкам - плевое дело.
Добавить поле - даже в код лезть не надо.
и т.п.

Все тоже самое на геттерах-сеттерах - чистой воды чайна-код.
Это всё замечательно до тех пор пока нам не понадобится в эти таблички интегрировать бизнес-логику.
...
Рейтинг: 0 / 0
11.01.2017, 13:02
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382235
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
забыл никА потом бац и надо поменять customerId(long) на customerUUID(String) :)
Так в том то и дело, что в описании и будет
Что-то типа
было
Код: javascript
1.
{"columns":[{"columnName":'Код клиента',"fieldName":'customerId'}...]}


стало
Код: javascript
1.
{"columns":[{"columnName":'Код клиента',"fieldName":'customerUUID'}...]}


и клиентская часть рисующая табличку отображает другой столбец.

В случае, если надо менять запрос, конечно все сложнее. Но в случае геттеров-сеттеров надо гарантированно перепахивать больше кода.

Собственно геттеры-сеттеры в любом случае скрывают способ хранения property. Хранить их в map немного увеличивает накладные ресурсу, но добавляет гибкости. И избавляет от кучи кода (Даже если он весь в @)
...
Рейтинг: 0 / 0
11.01.2017, 13:03
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382236
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
BlazkowiczЭто всё замечательно до тех пор пока нам не понадобится в эти таблички интегрировать бизнес-логику.
Надо - геттеры и сеттеры к твоим услугам, тыж поди все одно поля public не делаешь? :)
...
Рейтинг: 0 / 0
11.01.2017, 13:05
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382267
забыл ник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
забыл ник
Участник
Сергей Арсеньеви клиентская часть рисующая табличку отображает другой столбец.

И чем это отличается от аннотаций? Кроме того что существенно увеличивает трудности с relations и всякими join? Далее проблемы со всякими лэйзи-лоадинг и кешированием... Если не нравятся геттеры - то есть Lombok в конце концов
...
Рейтинг: 0 / 0
11.01.2017, 13:38
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382276
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Сергей АрсеньевНадо - геттеры и сеттеры к твоим услугам, тыж поди все одно поля public не делаешь? :)
Я делаю методы, которые работают с полями, а не геттерами-сеттерами. Это называется ООП.
...
Рейтинг: 0 / 0
11.01.2017, 13:50
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382289
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
BlazkowiczЯ делаю методы, которые работают с полями, а не геттерами-сеттерами. Это называется ООП.
Возможность методов работать с другими методами - тоже часть ООП. :)
...
Рейтинг: 0 / 0
11.01.2017, 14:08
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382298
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
забыл никИ чем это отличается от аннотаций? Кроме того что существенно увеличивает трудности с relations и всякими join?
Этот подход (хранить в map, а не в полях класса) не создает никаких трудностей ни с join ни с другими relations. Ибо можно скормить хоть тому же Hibernate если очень захочется (ему собственно по барабану). Или самому написать запрос любой сложности.
А аннотации требуют а- изменения кода, а так внешний вид формы можно хранить хоть в табличке и запоминать, какой пользователь какие поля скрыл, какие растянул, в каком порядке переставил и т.п.
Более того, в отличии от аннотаций его не так сложно отправить на клиента, если там скажем javascript.

Если же говорить про подход делать мапирование нескольких сущностей БД в одну POJO, то есть как плюсы, так и минусы.
...
Рейтинг: 0 / 0
11.01.2017, 14:15
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382299
Фотография Blazkowicz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Blazkowicz
Участник
Сергей АрсеньевBlazkowiczЯ делаю методы, которые работают с полями, а не геттерами-сеттерами. Это называется ООП.
Возможность методов работать с другими методами - тоже часть ООП. :)
Ну, если у вас большинство акцессоров приватные, тогда ладно. В принципе, если знать о проблеме, то можно её избежать. Тогда единственным минусом остаётся слегка уродливый код на акцессорах. Методы, которые работают с полями, обычно, более лаконичны.
...
Рейтинг: 0 / 0
11.01.2017, 14:15
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382341
Сергей Арсеньев
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Сергей Арсеньев
Участник
BlazkowiczМетоды, которые работают с полями, обычно, более лаконичны.
Так я и писал - зависит от задачи.
Если надо обрабатывать сразу группу полей, то проще их в map загнать. (будет как раз лакониченее)
Если по одному - каждое в отдельное поле.
И то и другое - getter и map.
...
Рейтинг: 0 / 0
11.01.2017, 15:07
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382499
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
slavik_mscт.е. правильно ли я понимаю:
у меня три класса:
что вы так в классы упёрлись?
Если у вас на клиенте будет большая простыня сводных данных, то нафиг вам эти 3 класса?
Без связки БД-->БЛ-->ГУИ нет смысла говорить о количестве классов.
- делайте ОДНУ страничку VIEW-ГУИ. И под табличку в ГУИ(возможно JSON) будете делать свои классы.
...
Рейтинг: 0 / 0
11.01.2017, 17:07
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382541
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
Petro123что вы так в классы упёрлись?
Если у вас на клиенте будет большая простыня сводных данных, то нафиг вам эти 3 класса?
Без связки БД-->БЛ-->ГУИ нет смысла говорить о количестве классов.
- делайте ОДНУ страничку VIEW-ГУИ. И под табличку в ГУИ(возможно JSON) будете делать свои классы.

Уперся потому что хочу сделать нормально.
Простыня не такая уж и длинная.
Вот и пытаюсь связать БД->БЛ->ГУИ. Стараюсь сделать слоенный пирог, в основе которого Spring MVC, сейчас использую spring-jdbc, позже когда всё заработает добавлю ORM.
Еще позже добавлю Spring Security.
А там может еще чего то, поэтому стараюсь делать правильно, чтобы можно было масштабировать.
...
Рейтинг: 0 / 0
11.01.2017, 17:40
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39382705
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
slavik_mscУперся потому что хочу сделать нормально.
ну тогда тут нет темы для обсуждения на 2 страницы.
- академически правильно в DAO - все таблицы представить объектами. Сколько таблиц - столько классов.
Т.е. DAO убирает и маскирует СУБД.
Берёшь и делаешь свой Helo World из 3-х таблиц как положено.
После того как будет готово, можно посомневаться
...
Не повторяйте DAO!
http://www.ibm.com/developerworks/ru/library/j-genericdao/
Это только пример того что надо всё пробовать самому).
Удачи!
...
Рейтинг: 0 / 0
11.01.2017, 20:49
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39383590
slavik_msc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
slavik_msc
Участник
Подскажите пожалуйста, я к каждому классу который соответствует своей таблице в БД, делаю слой DAO и слой сервиса.
И итоге есть класс который использует много объектов других классов, я могу использовать в слое DAO этого класса сервисы других классов? Насколько правильно так делать?
...
Рейтинг: 0 / 0
12.01.2017, 21:19
| Ответить | Цитировать | Написать  
Архитектура DAO
    #39383605
Фотография Petro123
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Petro123
Участник
slavik_mscИ итоге есть класс который использует много объектов других классов
Откуда мы знаем что там у вас за класс "в итоге". Вы бы код привели.
ЗЫ. Бизнес логика делается повыше в сервисном слое.
...
Рейтинг: 0 / 0
12.01.2017, 21:47
| Ответить | Цитировать | Написать  
43 сообщений из 43, показаны все 2 страниц
  все  
Форумы / Java [игнор отключен] [закрыт для гостей] / Архитектура DAO
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?all=1&fid=59&tid=2123267]:
 0ms
get settings:
 10ms
get forum list:
 17ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 44ms
get topic data:
 8ms
get forum data:
 2ms
get page messages:
 60ms
get tp. blocked users:
 1ms
others: 243ms
total:  391ms
созд. / загр.: 391ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]