Что такое хорошая (аккуратная) архитектура в программировании простого веб-сайта, например, книги контактов?

Когда я создаю простой веб-сайт, например, книгу контактов, где я могу добавлять, удалять и обновлять контакты, я создаю index.phpфайл, в котором пользователю, если он не вошел в систему, предлагается ввести пароль, и если он вводит правильный пароль, он назначил сеанс и может делать определенные вещи с контактами.

У меня есть два файла:

1. Первая ( contacts.php) предназначена для отображения HTML-кода. Над HTML-кодом я включаю второй файл и создаю класс.
2. Второй ( contacts_class.php) содержит все методы для добавления, удаления и обновления.

Я думаю, что все в порядке, но когда нужно реализовать большой проект, как мне это сделать? Нужно ли создавать папки для каждой страницы и помещать в них файлы (как выше, HTML и класс), и как мне это сделать? Что такое хорошая и аккуратная архитектура для построения больших проектов, которую любой другой программист прекрасно понимает?

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

На сегодняшний день наиболее распространенным подходом к созданию архитектуры инфраструктуры CMS является использование шаблона MVC. Есть некоторые хорошие статьи о строительстве собственных рамок MVC, один из них Сборка MVC Framework с PHP .

MVC расшифровывается как Model, View, Controller. Вы можете назвать эти подходы как угодно - MVC, HMVC, MVP. Суть в том, чтобы изолировать отдельные компоненты вашей системы. «Контроллер» извлекает данные из «Модели» и отправляет их в «Просмотр», который отображает окончательный HTML. Вы уже внедрили «V» в вашем contacts.phpи «MC» в вашем contacts_class.php. Итак, вы изолировали вид от модели и контроллера. Теперь вы можете легко изменить свой «Вид», оставив другие части без изменений.

Я не предлагаю вам слепо следовать MVC, MVP или какому-либо еще шаблону "MV". Это вопрос уместности, эффективности и вкуса.

Обычное динамическое веб-приложение может включать такие компоненты, как:

• Точка входа, скажем index.php
• Вспомогательные библиотеки / классы
• Маршрутизатор запросов
• Модули, компоненты или контроллеры
• Шаблонный движок или возможно отдельные представления

Настоящее веб-приложение может включать любые другие компоненты, такие как обработчики событий, диспетчеры событий и ловушки, но на самом деле это нюансы. Что ж, позвольте мне представить это так, как я хочу представить:

Процедура работы с общей структурой выглядит следующим образом:

1. Запрос браузера отправляется непосредственно в точку входа исполняемый файл / script ( index.php).
2. Сценарий точки входа загружает вспомогательные библиотеки, классы и выполняет некоторую дальнейшую инициализацию нашей среды программирования.
3. URL передается экземпляру маршрутизатора запроса. Этот шаг может быть частью шага 2.
4. Маршрутизатор запросов анализирует URL-адрес и отправляет операцию определенному компоненту, модулю или контроллеру.
5. Компонент (или контроллер) обрабатывает перенаправленный запрос и отправляет данные в представление для визуализации.

Соответствующая структура папок проекта показана на диаграмме.

Я хотел бы предложить вам изучить, как реализованы другие структуры. Для начала рекомендуется использовать CMS / frameworks: CodeIgniter, OpenCart, Joomla 1.5 и Tango CMS.

Чтобы понять, какие вопросы задавать и какие решения доступны, я рекомендую книгу « Образцы архитектуры корпоративных приложений » Мартина Фаулера. Вы можете получить представление о том, что в книге, прочитав его веб-сайт

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

(Программное обеспечение) Архитектура - это очень широкий вопрос, не ожидайте серебряной пули, но всегда больше вопросов и сомнений, пока не истечет время и деньги, и пока вам не придется выбирать лучшее решение.

Прежде всего, взгляните на хорошо разработанный проект. Wordpress - очень хороший пример структуры кода: он прост для понимания, но предлагает много «плагинов». Так что WordPress легко понять с помощью «подключить».

Во-вторых, очень простой способ проверить вашу архитектуру - это написать модульный тест. Например, если в классе «Колода карт» есть метод «shuffle ()», вы должны иметь возможность создать колоду карт заранее определенного размера (т. Е. 5 карт 1,2,3,4,5), вызвать shuffle и проверить в простой способ получить результат (id 1,4,2,5,3)

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

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

Затем повторите этот шаг для всех основных классов вашего проекта.

И последнее, но не менее важное: хорошая архитектура может быть «ленивой» для неосновных классов (это вопрос экономики: очень хорошо разработанные вещи стоят слишком дорого в реальном мире).

Хорошей архитектурой для крупномасштабных проектов является MVC (Model View Controller): http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller

Однако понимают ли другие программисты, что это совсем другое дело. MVC может быть сложным и иногда излишним для небольших проектов. Одним из преимуществ этого является то, что он легко масштабируется.

Если я правильно понимаю ваш вопрос, вы говорите о структуре папок проекта, а не об архитектуре. Если мое понимание верно, читайте дальше; иначе отредактируйте свой вопрос или оставьте комментарий, и я отредактирую свой ответ соответственно.

При разработке приложения, после ответа на некоторые основные вопросы, такие как (что? И для кого?), Мы должны определить компоненты и классифицировать их на основе функциональности \ обязанностей. Есть два основных способа, которые я знаю. Вы можете классифицировать компоненты на основе, варианты использования, которые они обрабатывают (например, вход в систему, поиск и т. Д.) Или классифицировать на основе ресурсов (объекты ..). Первый способ называется «Ориентированный на активность», а второй - «Ориентированный на ресурсы». Традиционно большинство приложений классифицируют компоненты на основе действий (поскольку разработчики нашли это, их легко переносить из проблемного домена в домен решения). Но я отвлекся.

Как только классификация компонентов определена, нам нужно определить классификацию на основе уровней. Типичное веб-приложение будет иметь уровень представления, уровень модели и уровень контроллера (MVC). Конечно, могут быть и более сложные приложения. (большинство реальных приложений более сложны, чем просто).

После идентификации этих двух таксономий я создам папки верхнего уровня, идентифицирующие каждый уровень. (Пользовательский интерфейс, контроллер, сервисы, утилиты и т. Д.). Под каждой папкой высокого уровня я буду создавать дочерние папки на основе функциональности или ресурсов (Project - / EditProject - / SearchProject и т. Д.). В идеале функциональная классификация будет многоуровневой.

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

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

Архитектура - это гарантия того, что вы сможете продолжать развиваться в долгосрочной перспективе. Для более крупных приложений это включает в себя компромисс между независимостью, чтобы несколько человек могли работать одновременно, и избегая дублирования (DRY), чтобы проект оставался гибким. Проекты PHP, как правило, направлены на то, чтобы сделать вещи независимыми и имеют большое количество дубликатов.

Чтобы почувствовать другую крайнюю позицию, взгляните на Приморский

Если вы не знаете, как структурировать большой проект, вы должны заимствовать дизайн / архитектуру других, используя один из нескольких хороших фреймворков PHP. Я бы порекомендовал CakePHP, CodeIgniter или Symfony. Все они реализуют паттерн Model, View, Controller, MVC, который хорошо работает в веб-разработке, все они довольно легки и просты в освоении.

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

MVC является наиболее часто используемой архитектурой, которая, как доказано, решает большинство проблем. Хорошая архитектура будет иметь следующие функции (и многое другое, конечно)

1. Это может быть проверено модулем
2. Разделение интересов
3. Несколько людей смогут работать над ним без каких-либо столкновений.
4. Это может быть продлено без особых проблем
5. Это может быть масштабируемым. Когда дело доходит до больших проектов, масштабируемость будет серьезной проблемой. Платформа Kohana Checkout , которая хорошо написана и хорошо масштабируется

прежде чем писать какой-либо производственный код, потратьте 2 недели (ночи :) и прочитайте эту книгу. Это надолго изменит ваше мнение об архитектуре программирования, правилах и упаковке.

Agile принципы, шаблоны и практики C # от Прентис Холл

Примеры есть в C #, но их легко прочитать, речь идет не о том, как написать правильный синтаксис кода, а о том, как думать как программист.

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