Как начать большой новый проект ZF2?

Question

Я собираюсь создать новый проект с ZF2. На самом деле мне придется обновить проект ZF1, но я решил начать с нуля.

Мой проект очень большой и уже переведен на 10 разных языков добровольцами со всех уголков мира.

Сложность, которую я испытываю, - это анализ структуры модулей, которые ZF2 мне подсказывает.

Программное обеспечение позволяет МСП в мире ISP управлять своей клиентской базой данных, услугами, заказами, счетами, доменами, технической помощью, электронной коммерцией, kb и т. Д.

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

Например:

Мои работает приложение:

• Клиенты
• Заказы
• счетов-фактур
• Платежи
• Сообщения
• Личные примечания

Вот скриншот веб-интерфейса проекта:

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

Какую стратегию вы посоветуете мне принять структуру крупного проекта?

Answer 1

Я сам в настоящее время работаю над очень крупным проектом в ZF2 и считаю, что ключ к успеху охватывает модульность, предлагаемую каркасом.

Некоторые указатели я чувствую бы полезно:

• создать абстрактный/базовый модуль

  Создание «базы» модуль позволит вам содержать большую часть общих/абстрактных интерфейсов/классы, которые могут быть использованы в любом модуле. Это будет означать, что базовый модуль является зависимостью друг от друга модуля внутри системы.

• модули имеют взаимозависимости

  Некоторые модули, хотя и отделенные будет зависеть от функциональности других модулей (платежи могут нуждаться в информации о пользователях, например).

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

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

• Эффективного сервис слой

  Действительно общий принцип проектирования MVC Однако убедитесь, что вы не кодирование бизнес-логики в контроллере, а использовать классы «сервис» инжектированные в контроллеры. Если вы этого не сделаете, вы быстро найдете его неуправляемым.

• Создание Фабрики Сервис

  Предпочитают конкретные заводские классы (классы реализации Zend\ServiceManager\FactoryInterface), как проставление к затворам иначе вы быстро обнаружите, что число фабрик вам нужно будет раздувать ваш Module.php и они не могут быть кэшируются подобно конфигурация - это значит, спектакль хит

• ViewPlugins/контроллер плагины

  Избегайте гибкости контроллера и просмотра плагинов. Это чрезвычайно эффективные способы инкапсуляции и ввода дополнительной логики просмотра/контроллера без необходимости расширения существующих классов.

• Формы

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

  Если у вас есть CompanyFieldset к примеру, вы можете использовать его в CompanyEditForm и CompanyCreateForm и CompanyEditForm

Пример из моего проекта:

class CompanyCreate extends EntityForm 
{ 
    public function init() 
    { 
    $this->add(array(
     'name' => 'company', 
     'type' => 'Company\Form\CompanyFieldset', // <-- reused!! 
     'options' => array(
     'use_as_base_fieldset' => true 
    ) 
    )); 
    // Only the button differs between forms! 
    $this->add(array(
     'name'  => 'submit', 
     'priority' => -100, 
     'options' => array(
     'skipLabel' => true, 
    ), 
     'attributes' => array(
     'type' => 'submit', 
     'class' => 'btn', 
     'value' => 'Create' 
    ) 
    )); 
    } 
} 

В терминах ваших модулей:

Мое приложение работает: Заказчики, Заказы, Счета-фактуры , Платежи, Сообщения, Частные примечания

Это похоже на хороший список автономных модулей для начала.

Я уверен, что есть больше, я буду обновлять, если я могу думать ни о чем

Answer 2

Модулей может быть много. И они могут быть совсем ничего. Это их очарование. Старайтесь не думать слишком сложно. Подумайте о NewsModule и CategoriesModule. Подумайте о склеивании этих двух вместе. Если вы справитесь с этим, большой проект, подобный вашему, будет таким же простым. Если вы не можете справиться с этим, вам лучше посоветовать подождать с началом нового проекта, пока вы не сможете это сделать.

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

Для начала ваше «мое приложение работает» -List выглядит как хорошее первое разделение независимых модулей. Хитрость заключается в том, чтобы простые интерфейсы, так что адаптеры легко взаимозаменяемы (Customer < -> Orders).