• Пространства имен, как они работают?

    nazarpc
    @nazarpc
    Open Source enthusiast
    Во-первых php-script нельзя, будет синтаксическая ошибка.
    Во-вторых пространства работают как у вас в коде, вот только вам в придачу к показанному коду ещё нужен автозагрузчик классов, который является отдельной штукой и ничего не имеет общего с пространствами имен как таковыми. Чаще всего в качестве загрузчика выступает vendor/autoload.php, сгенерированный для вас Composer-ом во время установки пакетов. Можно и свой написать если нужно.
    Ответ написан
  • Пару вопросов по MVC. Поможете?

    Fesor
    @Fesor
    Full-stack developer (Symfony, Angular)
    что посоветуете?


    1) забудьте об MVC на минутку. Пока мы будем говорить о "модели". Так же пока забудьте о представлении, HTML и т.д. Только PHP, только хардкор.
    2) вынесите все действия в отдельные классы, что-бы у вас был по объекту на действие
    3) вынесите все дублирование в отдельные объекты (это что бы конкретизировать что подразумевается под вторым пунктом) и вынесите все в зависимости
    4) поскольку у вас стало много объектов - воспользуйтесь контейнером зависимостей
    5) для работы с базой данных имеет смысл организовать DAO например. То есть что бы все что относится к SQL что бы было как-то сокрыто в них а не размазано по всем объектам. Так же можете почитать на тему Table Data Gateway.

    То есть у нас должно сформироваться некое API. Нам нужны новости - достаем объект, который умеет их доставать. Нужно что-то еще - для этого чего-то тоже найдется объект умеющий это. Как он будет это делать - дело третье.

    Далее, надо добавить прослойку, которая будет конвертировать данные возвращаемые предыдущим API, в тот формат, в который мы хотим. Это будут контроллеры по сути. Для них нужен роутер, шаблонизатор и т.д.

    Дабы устранить дублирования UI-ки имеет смысл выделить отдельные компоненты (например блок с последними новостями - отдельный UI компонент). То есть страница будет собираться как-бы из кусочков.

    Ну как-то так.
    Ответ написан
  • Как вы освоили шаблоны проектирования?

    dmitry_pavlov
    @dmitry_pavlov
    World-class .NET freelance contractor (remotely)
    Когда начался бум и восторг вокруг концепции паттернов проектирования, выкрики "GoF рулит!" и так далее, я озадачился тем, чтобы понять, что за шум?

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

    По аналогии в проектировании софта имееются свои архитектурные вопросы вроде разбиения приложения на компоненты/модули, организации зависимостей между ними, распределение функциональных обязанностей и т.п. Как ловко подметили авторы книжки из этой банды четырех (The "Gang of Four") в нашей индустрии можно также выделить некоторе количество типовых шаблонов, проверенных на практике, чтобы тем самым не наступать на уже обойденные другими грабли.

    Суть постижения паттернов заключается в том, чтобы осознать в каких ситуациях правильно использовать тот или иной шаблон проектирования и правильно его применить. Важно понимать при этом, что формула "чем больше паттернов я придумал засунуть с свое приложение - тем лучше" - неверная. Использовать их следует с умом и только там, где они действительно нужны. Кроме того, патерны устаревают, превращаются в анти-паттерны по мере развития технологий (которые в нашей области делают это более чем стремительно). Ну и, конечно, есть шаблоны общепринятые и есть те, которые успешно используются в узких кругах.
    Тут тоже надо понимать, что это не догма какая-то - типа 10 священных паттернов проектирования :)

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

    К изучению паттернов я дам такие советы:

    1) Прочтите пару книжек, чтобы понять, что это за зверь и с чем его едят. Можно взять одну из вариаций книжки GoF или какие-то производные для вашего стека разработки - познакомиться с основными популярными шаблонами. Сразу после этого я посоветовал бы прочесть книжку "Горький вкус Java" (Брюс Тейт) - она про анти-паттерны. Это чтобы понять обратную сторону их использования. Мне понравилась и уберегла думаю от многих проблем. То что на примере Java - неважно. Речь идет о шаблонах, так что представителям других стеков (к которым отношусь и я) будет просто понять все равно.

    2) Постарайтесь осознать, доводилось ли вам сталкиваться в работе раньше с чем-то, что является или могло бы легко стать одним из шаблонов. Где получалось применить концепт верно, а где из-за этого только проблемы были.

    3) В новых проектах, держите в голове полученные по шаблонам знания - вдруг пригодятся.

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

    Я даже пожалуй посоветовал бы подойти к освоению айтишной архитектурной мудрости с другой стороны - со стороны нефункциональных требований или так называемых "-ilities" - их много. Тут вот описаны 7 штук. А вообще их десятки.

    Среди прочих - такие как maintainability (простая поддержка кода), scalability (масштабируемость), extensibility (расширяемость), availability (устойчивость ) и тп. Если, проектируя свое приложение, вы задумываетесь об этих "илитях" и стараетесь их обеспечить в необходимом проекту объеме, то, как правило, ваше приложение будет иметь отличную архитектуру. При этом шаблоны проектирования в ней появятся лаконично сами собой.

    Поскольку идея использовать шаблоны - это попытка опытных программных инженеров дать десяток готовых рецептов менее опытным, чтобы пока они не научились варить "вкусную кашу", они не варили уж что-то совсем несъедобное. :) Учитесь "готовить", разбирайтесь в -ilites :) и все будет хорошо
    Ответ написан
  • Какой вариант лучше?

    DROP TABLE IF EXISTS `t_content`;
    
    CREATE TABLE `t_content` (
      `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
      `type` enum('blog','news','page') DEFAULT NULL,
      `alias` varchar(255) DEFAULT NULL,
      `title` varchar(555) DEFAULT NULL,
      `content` text,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB DEFAULT CHARSET=utf8;
    
    LOCK TABLES `t_content` WRITE;
    /*!40000 ALTER TABLE `t_content` DISABLE KEYS */;
    
    INSERT INTO `t_content` (`id`, `type`, `alias`, `title`, `content`)
    VALUES
    	(1,'blog','eto_statia_bloga','Это статья блога','Контент'),
    	(2,'news','eto_novost','Это новость','Текст новости'),
    	(3,'page','kontacty','Контакты','Обычная страница, например с контактами');
    
    /*!40000 ALTER TABLE `t_content` ENABLE KEYS */;
    UNLOCK TABLES;
    Ответ написан
  • Виновен ли я в самописном движке?

    @Bezlepkin
    Yii, PHP, JS, Android
    Как дети малые! Первое! Сколько стоит сайт!? А сколько его делать дней? Сколько человек принимает участие? Вот и считай. Возьмём твою сумму 12000, ты работал три недели допустим по 8 часов. 571 руб. В день, 71 руб. В час. Стоит задуматься...

    Второе! В чем разница самопис или CMS?

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

    Писать свой движок можно, но не уж с нуля. Во первых будет много дыр, во вторых долго, и самое важное! Заказчику нужно сделать так чтоб он не был привязан к тебе. Хочешь движок, сделай на framework.

    Сейчас клиентам нужно делать под ключ.

    Сам сделал сайт, сам и раскручивай. Нужно подсадить клиента, доить его :)
    Ответ написан