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


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