ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Java [игнор отключен] [закрыт для гостей] / Правильный подход к полям бина
17 сообщений из 17, страница 1 из 1
Правильный подход к полям бина
    #34472956
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oson
Участник
Господа!
Подскажите правильный подход к обновлению полей бина.
Есть обычный JavaBean с тремя полями
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
 public   class  RegistrationCompany
    {
         private  List processes;
         private  RegistrationCompanyProcess activeProcess;
         private  Company company;

          public   void  addNewProcess(Company company)
        {
             this .company = company;
             this .activeProcess = createRegistrationCompanyProcess(сompany);
            getProcessDAO() .save(activeProcess);
             this .processes = getProcessDAO().getProcessesByCompany();
         }
      
         public  List getProcesses()
        {
             return  processes;
        }

       
         public  RegistrationCompanyProcess getActiveProcess()
        {
             return  activeProcess;
        }

     
         public  Company getCompany()
        {
             return  company;
        }

    }

То есть при вызове метода addNewProcess я сразу проинициализировал поля company,activeProcess и processes и например когда мне на странице надо вывести табличку
processes, то я просто вызываю public List getProcesses().
Или правильнее проинициализировать только например company, а считывание из базы processes
по company поместить в getProcesses()?
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
   public   class  RegistrationCompany
    {
         private  List processes;
         private  RegistrationCompanyProcess activeProcess;
         private  Company company;

         public   void  addNewProcess(Company company)
        {
             this .company = company;
            getProcessDAO() .save( createRegistrationCompanyProcess(сompany));
        }
      
         public  List getProcesses()
        {
             return   getProcessDAO().getProcessesByCompany();

        }

        
         public  RegistrationCompanyProcess getActiveProcess()
        {
             return  getProcessDAO().getActiveProcessByCompany();        
        }

        
         public  Company getCompany()
        {
             return  company;
        }

        
     }
...
Рейтинг: 0 / 0
19.04.2007, 14:41:47
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34472980
y3u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
y3u
Участник
все зависит от того как ты собираешься использовать этот класс. Как в объекте в нем есть смысл только если ты делаешь что-то вроде кеша. Я что-то не совсем пойму егореальное назначение. Если тебе просто нужен утильный классик по работе с данными из БД, то он не должен содержать ни каких полей и иметь приватный конструктор по умолчанию...
...
Рейтинг: 0 / 0
19.04.2007, 14:47:43
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34473137
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oson
Участник
При логине юзера этот класс создается и кидается в сессию и сопровождает этого юзера пока он не разлогиниться. По списку processes например строится меню процессов, которые относятся к этому юзеру. А когда он щелкает по одному из этих линков - то меняется activeProcess и поля страницы заполняется соответствующими ему данными. Так вот я каждый раз - то ли при первом логине, то ли при смене активного процесса, то ли при создании нового процесса делаю примерно вот так
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
   public   void  addNewProcess(Company company)
        {
             this .company = company;
             this .activeProcess = ProcessHelper.createRegistrationCompanyProcess(company);
            getProcessDAO() .save(activeProcess);
             this .processes = CMHelper.getProcessDAO().getRegistrationCompanyProcessesByRole(role);
        }
и уже на странице выводиться все по геттерам
Код: plaintext
1.
2.
3.
4.
    public  RegistrationCompanyProcess getActiveProcess()
    {
             return  activeProcess;
    }
то есть при смене например activeProcess я должен проапдейтить поле бина company
новой компанией
Код: plaintext
1.
2.
3.
4.
5.
6.
    public   void  changeActiveProcess( Long  id)
    {
         this .activeProcess = (RegistrationCompanyProcess)getProcessDAO().getById(id);
         this .processes = getProcessDAO().getRegistrationCompanyProcessesByRole(role);
         this .company = getCompanyDAO().getByProcess(activeProcess);
    }
и храню эту новую компани в поле company, пока ктото ее не вызовет через геттер.
Вот и вопрос - правильно ли так кэшировать и хранить поля, или надо их получать в самих геттерах при вызове - то есть например когда company понадобилась гдето на страничке, прямо
в геттере сделать
Код: plaintext
1.
2.
3.
4.
5.
   public  Company getCompany()
  {
      return  getCompanyDAO().getByProcess(activeProcess);

  }
...
Рейтинг: 0 / 0
19.04.2007, 15:21:58
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34473175
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expp
Участник
обращение из домена к DAO - НЕТ!!!
...
Рейтинг: 0 / 0
19.04.2007, 15:29:21
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34473238
y3u
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
y3u
Участник
я бы стал морочиться кешированием только если будут проблемы с производительностью... еще что-то мне совсем не хочется это все класть в сессию, можно табличку завести в БД user_id, active_process_id... ИМХО...
...
Рейтинг: 0 / 0
19.04.2007, 15:41:46
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34473368
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oson
Участник
exppобращение из домена к DAO - НЕТ!!!
Стыдно, но я не знаю что такое домен в данном контексте :(
...
Рейтинг: 0 / 0
19.04.2007, 16:09:08
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34473391
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oson
Участник
На самом деле я думал так-
В сессии обычно храниться логин юзера после того как он залогиниться и на каждой странице проверяется, имеет он там права или нет ну и тому подобное.
Я и подумал - а почему туда не положить целый класс, который при логине определяет юзера -
поле user - его роль - role - да потом еще и считывает по этой роле все принадлежащие ей процессы - processes. Получается когда юзер залогинился,в меню сразу появляется список процессов, остроенный по этому List processes. А когда он щелкает на одном из них, то меняется
activeProcess и выводится вся информация по нему. Все это рабтает. Но вот во-первых правильно ли хранить такой обьект в сессии , есть ли возражения против этого; а во-вторых, обновлять поля
этого класса (то есть хранить processes, activeProcess как поле класса) или перечитываь их из базы каждый раз.
И третье - что значит я из домена к ДАО обращаюсь :(
...
Рейтинг: 0 / 0
19.04.2007, 16:16:00
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34473538
ТимоН
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ТимоН
Участник
ИМХО неправильное использование бинов. Бины по идее это простые обьекты с сеттерами и геттерами.
авторЯ и подумал - а почему туда не положить целый класс, который при логине определяет юзера -
поле user - его роль - role - да потом еще и считывает по этой роле все принадлежащие ей процессы - processes.
Я бы создал бин User + Класс логики которую вы хотите реализовать вынес на контроллер.
...
Рейтинг: 0 / 0
19.04.2007, 16:47:51
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34473577
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expp
Участник
ф точку http://www.infoq.com/minibooks/domain-driven-design-quickly
...
Рейтинг: 0 / 0
19.04.2007, 16:54:53
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34476266
Jozic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Jozic
Участник
exppобращение из домена к DAO - НЕТ!!!+1
...
Рейтинг: 0 / 0
20.04.2007, 14:50:35
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34477229
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oson
Участник
Jozic exppобращение из домена к DAO - НЕТ!!!+1
-приборы
-10
-что десять?
-что приборы?
...
Рейтинг: 0 / 0
20.04.2007, 18:16:56
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34478302
seacat
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
seacat
Гость
oson Jozic exppобращение из домена к DAO - НЕТ!!!+1
-приборы
-10
-что десять?
-что приборы?
Domain model (домен) это бины предметной области. Обращаться из этих бинов к dao не рекомендуется. Введите дополнительный слой - service layer или buisness layer, что собственно и советует ТимоН.
...
Рейтинг: 0 / 0
21.04.2007, 22:10:11
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34506651
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oson
Участник
Вопрос интересный.
Я сейчас разбираюсь с jboss seam - так там в примерах прямо из stateful session bean идет обращение в базу - безо всяких DAO.
В обычных JSF из JavaBean так наз предметной области - ну то есть в котором непосредств проходят бизнес процессы, вызываемые кликами на страничке - обращение идет к DAO и оттуда в базу. Но почему это порочно и зачем еще один уровень вводить между JavaBean предм области и DAO?
...
Рейтинг: 0 / 0
05.05.2007, 11:29:08
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34508501
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expp
Участник
Даю справку:

DAO изобретено во времена EJB2 и Model2 (Servlet+JavaBean+JSP) для решения специфических проблем: bean <-> sql.

Domain Driven, ORM, Hibernate - совсем другая штука. тута и тута

теперь
osonВопрос интересный.
Я сейчас разбираюсь с jboss seam - так там в примерах прямо из stateful session bean идет обращение в базу - безо всяких DAO.
StSB обращаеться к entityManagerу абстракции репозитория, а не DAO
oson
В обычных JSF из JavaBean так наз предметной области - ну то есть в котором непосредств проходят бизнес процессы, вызываемые кликами на страничке - обращение идет к DAO и оттуда в базу. Но почему это порочно и зачем еще один уровень вводить между JavaBean предм области и DAO?
Отделяем мухов от котлетов.
JSF решает Web и остальную архитектуру не навязывает. С entity-JavaBean можно связать поля ввода. Но кнопку лучше сбиндить с action-JavaBean'ом, который обновит entity через Service/Repository/DAO.
Ещё вопросы?
...
Рейтинг: 0 / 0
07.05.2007, 09:12:12
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34515723
Фотография oson
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
oson
Участник
Давайте определимся в терминах.
В случае использования JSF и Hibernate безо всяких EJB :
имеем т.н. Backing beans - plain JavaBeans - в различных scopes - Session, Request - которые реагируют на события, производимые юзером на страничке, и имеем т.н. BusinessObjects, которые через hibernate мэпятся в базу. Из метода Backing bean через DAO загружаем, апдейтим, создаем
Business objects и соответственно записи в соответствующих таблицах. Куда здесь надо еще один layer добавлять?
В случае с EJB3 например в Seam
На страничке нажимаем кнопку - в SessionBean срабатывает привязанный к кнопке метод и прямо
из SessionBean загружаем, апдейтим, создаем EntityBeans и соответсвующие записи в базе.
Типа такого
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
 @Stateful
 ...
   public   class  HotelBookingAction  implements  HotelBooking
 {
     @PersistenceContext(type= PersistenceContextType.EXTENDED)
      private  EntityManager em;
     ...
      public   void  getBookings()
    {
      bookings = em.createQuery("select b from Booking b where b.user.username = :username order    
      by   b.checkinDate")
     .setParameter("username", user.getUsername())
     .getResultList();
    }
    ...
 }
вопрос - нормально вот так прямо безо всяких промежуточных лайеров делать запросы из Session bean?
...
Рейтинг: 0 / 0
10.05.2007, 11:58:32
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34516106
i23m
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
i23m
Участник
по-моему будут работать оба ваших варианта
но я бы выбрал второй. просто потому, что он нагляднее и ближе и теории, что-ли
...
Рейтинг: 0 / 0
10.05.2007, 13:28:17
| Ответить | Цитировать | Написать  
Правильный подход к полям бина
    #34516276
expp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
expp
Участник
2 oson

1. повторюсь: Hibernate и DAO - как корова и седло созданны другдля друга.
2. Про ваш вопрос. ортодоксальный подход: backing bean (Presentation Layer) пинает Service (лучше через Facade), а тот реализует логику usecase (обращаясь к Repository) т.е. обновляет Entity.
3. Термин BusObj не считаю удачным. Я его в дотнете встречал, мне кажется тут смешиваются Entity и Service.
4. сам пользуюсь терминологией и идеологией из "POJO in Action" и "Domain Driven Design"
5. согласен что такой раздутый стэк это недостаток жабы, но имхо это удовлетворяет условию необходимости: (Entity, Repository, Service, Facade, Action) .
6. когда Service, Facade, Action, Repository в Seamе сливают в один клас - я за. Для небольших быстрых проектов это самое то.
...
Рейтинг: 0 / 0
10.05.2007, 14:12:28
| Ответить | Цитировать | Написать  
17 сообщений из 17, страница 1 из 1
Форумы / Java [игнор отключен] [закрыт для гостей] / Правильный подход к полям бина
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/search_topic.php?author=sameuser66&author_mode=last_topics&do_search=1]:
 0ms
get settings:
 10ms
get forum list:
 21ms
get settings:
 14ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 39ms
get topic data:
 13ms
get forum data:
 3ms
get page messages:
 75ms
get tp. blocked users:
 2ms
others: 609ms
total:  808ms
созд. / загр.: 808ms
x
x
Закрыть


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