Вопросы Теги

Шаблон репозитория: как к Ленивой Загрузке? или, я должен разделить этот Агрегат?

Существует три основные причины.

  1. FacesServlet не вызывается.
  2. Недопустимые URI пространства имен XML.
  3. Несколько JSF были загружены.

1. Убедитесь, что URL-адрес соответствует FacesServlet mapping

. URL-адрес ссылки (URL-адрес, который вы видите в адресной строке браузера) должен соответствовать файла FacesServlet, как определено в web.xml чтобы все работы JSF выполнялись. FacesServlet - это тот, который отвечает за разбор файла XHTML, сбор представленных значений формы, выполнение преобразования / проверки, обновление моделей, вызывание действий и создание выходных данных HTML. Если вы не вызываете FacesServlet по URL-адресу, то все, что вы получили (и увидите через rightclick, View Source в браузере), действительно является исходным исходным кодом XHTML.

Если , например, *.jsf, ссылка должна указывать на /register.jsf, а не на /register.xhtml. Если это, например, /faces/*, как и у вас, ссылка должна указывать на /faces/register.xhtml, а не на /register.xhtml. Один из способов избежать этой путаницы - просто изменить с /faces/* на *.xhtml. Таким образом, нижестоящее является идеальным отображением: 


    facesServlet
    javax.faces.webapp.FacesServlet


    facesServlet
    *.xhtml

Если вы по какой-то причине не можете поменять на *.xhtml, то вы, вероятно, также хотели бы, чтобы конечные пользователи не могли напрямую обращаться к источнику XHTML кодировать файлы по URL-адресу. В этом случае вы можете добавить в в *.xhtml с пустым в web.xml, который предотвращает это: 


    Restrict direct access to XHTML files
    
        XHTML files
        *.xhtml

Предстоящий JSF 2.3 решит все из вышеперечисленного, автоматически регистрируя FacesServlet в шаблоне URL-адреса *.xhtml во время запуска webapp.

См. также:

2. Убедитесь, что пространства имен XML соответствуют версии JSF

. С введением JSF 2.2 еще одна вероятная причина заключается в том, что пространства имен XML не соответствуют версии JSF. xmlns.jcp.org, как показано ниже, является новым с JSF 2.2 и не работает в старых версиях JSF. Символы почти такие же, как если бы FacesServlet не вызывался.

Если вы не можете перейти на JSF 2.2, вам нужно вместо этого использовать старые пространства имен java.sun.com XML:

См. также:

3. Было загружено несколько реализаций JSF

. Еще одна вероятная причина заключается в том, что несколько реализаций JSF были загружены вашим webapp, конфликтуя и разлагая друг друга. Например, когда ваш путь к классу среды выполнения Webapp загрязнен несколькими различными версиями JSF-библиотек или в конкретной комбинации Mojarra 2.x + Tomcat 8.x, когда в файле web.xml веб-приложения есть ненужная запись ConfigureListener, вызывающая ее загрузку дважды. 





    com.sun.faces.config.ConfigureListener

При использовании Maven убедитесь, что вы правильно определяете зависимости и понимаете области зависимостей. Важно: не связывайте зависимости в webapp, если они уже предоставлены целевым сервером.

См. Также:

Убедитесь, что вы учитесь JSF правильный путь

JSF имеет очень крутую кривую обучения для тех, кто не знаком с базовыми HTTP , HTML и сервлетами . В Интернете много ресурсов низкого качества. Пожалуйста, игнорируйте фрагменты скриншотов кода, поддерживаемые любителями, в основном ориентированные на доход от рекламы, а не на обучение, такие как розы, учебник, javabeat и т. Д. Они легко узнаваемы, нарушая рекламные ссылки / баннеры. Также, пожалуйста, игнорируйте ресурсы, связанные с юрским JSF 1.x. Они легко узнаваемы с помощью JSP-файлов вместо файлов XHTML. JSP как технология просмотра устарела с тех пор, как JSF 2.0 уже в 2009 году.

Чтобы начать правильно, начните с нашей вики-страницы JSF и закажите авторитетную книгу .

См. также:

40
задан Jim G. 4 October 2009 в 03:06
поделиться

4 ответа

Неправильно ли я истолковываю цель шаблона репозитория?

Я скажу «да», но знайте, что я и все люди, с которыми я работал, спрашивали об одном и том же по той же причине ... «Ты не думаешь о 4-м измерении, Марти».

Давайте немного упростим его и сначала остановимся на конструкторах, а не на методах Create: 

Editor e = new Editor("Editor Name");
e = editorRepository.Add(e);

Project p = new Project("Project Name", e);
p = projectRepository.Add(p);

Внизу репозиторий вашего проекта всегда хранит действительного владельца ( p.EditorId ) в данные проекта по мере его создания, и, как бы вы ни повторно заполняли проекты редактора, он будет там. Вот почему рекомендуется помещать все необходимые свойства в конструкторы. Если вы не хотите передавать весь объект, подойдет только e.Id .

И если я хочу лениво загрузить членов Editors, Проекту также нужна ссылка на репозиторий?

Теперь, что касается того, как повторно заполнить проекты редактора по запросу, у вас есть несколько вариантов в зависимости от того, что вы собираетесь делать. Прямой репозиторий говорит, что вы хотите: 

IEnumerable<Project> list = projectRepository.GetAllProjects()
                                .Where(x => x.editorId == e.Id);

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

Далее идет уровень адаптера для вашего приложения с общим источником репозиториев ( StaticServiceWrapper ) и либо своего рода объектом EditorAdapter (или Aggregate, либо как вы их называете), либо теперь вы можете смешайте методы расширения, которые могут свободно общаться со всеми необходимыми репозиториями. Я не

30
ответ дан 27 November 2019 в 01:55
поделиться

Как насчет того, чтобы разделить обязанности на EditorOwner и EditorMember?

, не зная Ваш домен, я предположил бы, что у них будут различные обязанности - например, EditorOwner мог бы быть довольно богатым (и мог быть совокупный корень), но Проект, возможно, только должен знать ограниченную сумму о своих участниках, таким образом, объект EditorMember может быть довольно легким.

Эти объекты области могут также коснуться Пользователей, но это было бы в другом контексте.

, который помогает вещам, или просто делает его более сложным?

4
ответ дан Michael Hart 27 November 2019 в 01:55
поделиться

Это зависит от потребностей Вашего приложения. Если это - большая проблема загрузить все Проекты для данного Редактора, то попробуйте ленивый шаблон загрузки как Виртуальный Прокси .

Относительно ленивой загрузки членских Редакторов Проекта, если Вы используете Виртуальный Прокси, я не вижу проблемы ввести прокси с EditorRepository, так как я не полагаю, что прокси часть домена.

, Если Вы разделяете Агрегат, можно заняться расследованиями Единица работы шаблон как одно решение атомарности. Эта проблема, тем не менее, не уникальна для DDD, и я уверен, что существуют другие решения для транзакционного поведения.

3
ответ дан moffdub 27 November 2019 в 01:55
поделиться

Здесь у Вас есть 2 различных отношения, один для владения и один для членства.

отношение владения является простым многим (один владелец для каждого проекта). Отношение членства - многие многим (многие Редакторы проектом, многими проектами редактора).

Вы могли обеспечить свойство Owner на классе Проекта и предоставить метод на ProjectRepository для получения всех проектов, принадлежавших определенному Редактору.

Для многих отношения, обеспечьте членское свойство на классе Проекта и метод на ProjectRepository для получения всех проектов, содержащих указанного Редактора как участник.

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

0
ответ дан thinkbeforecoding 27 November 2019 в 01:55
поделиться
Другие вопросы по тегам:

Похожие вопросы: