что этим методом хотят скрыть? факт установки соединения остается. факт передачи данных тоже. чисто статистически «тайные» данные лучше передавать в обычных пакетах, ведь таких пакетов гораздо больше, чем ретрансмиссионных.
В современном мире, MVC это догма. Такая же как ОтецСынСвятойдух в христианстве. ;)
Техника расщепления приложения на слои описана у Фаулера в Patterns of Enterprise Application Architecture. В двухслойной архитектуре слои называются Client и Server. В трехслойной архитектуре — Presentation, DomainLogic и DataSource. Слоев может быть и больше. Дело не в названиях и их количестве. Суть в том, что на практике бывает полезно, сильно сцепленные куски логики приложения, обосабливать друг от друга (образуя между ними слабые коммуникационные связи). Например, хорошо отделять DomainLogic (логику, ради которой и создается система ⓒ), от прочего, неизбежно сопутствующего барахла, — UI и внешних API приложения с одной стороны, и источников/хранилищ данных с другой.
В большей части интерпретаций, MVC это принцип, который используется для анализа задач, связанных с созданием инструментов пользователя (Tools). С точки зрения MVC, все интересующие программные артефакты рассматриваются в аспекте представлений и их преобразований из одного в другое. View отражает представление некоторой артефакта, в терминах пользовательской ментальной модели, Model — представление в терминах программной модели, а Controller — представление в терминах управления. Например, инструмент для рейтингования этого коммента, с точки зрения MVC может рассматриваться следующим образом. Для юзера это изображение двух изумительных квадратиков: красного и зеленого — которые символизируют критику и одобрение. Для хабрасервера это строка из набора {'minus','plus'}. Для браузера — два мышекликабельных объекта.
И то и другое, в общем-то, являются самостоятельными концепциями, и не зависят от ООП.
② Когда люди обращаются к использованию паттернов проектирования?
На этапе анализа задачи то и дело возникает проблема идентификации сущностей и отношений между ними. Идентифицировать — значит выделить характерные особенности и придумать уникальное название. На «выходе» должен получиться этакий словарь терминов, наделенных определенным смыслом, при помощи которых, в дальнейшем, будет описываться все решение и составляться программная модель. Классно, если полученная модель будет не только описывать требуемые аспекты задачи, но и — хорошо вписываться в архитектурные решения любимой программной платформы, а так же будет понятна всем членам команды. Т.е. термины должны быть не абы-какими, а общеупотребимыми. Я думаю, что многие и на этом этапе начинают искать спасение в книжках по паттернам проектирования. Вам требуется создать приложение, которое будет взаимодействовать с пользователем? Смотрим книжку, вот и ответ: ModelViewController — всего три слова! Это элементарно и понятно даже «новичку». Значит нужно использовать паттерн MVC. Теперь сравните — MVC в Smaltalk, MVC в .Net.MVC и MVC во фреймворке symfony для php — за тремя одинаковыми словами скрываются четыре совершенно разных архитектурных решения (первое было в книжке). А что в вашей архитектуре будут означать слова ModelViewController? =)
Когда люди обращаются к использованию паттернов проектирования?
Все программисты, во время кодинга, сталкиваются с проблемой именования сущностей: как назвать класс?, как назвать метод?, как назвать атрибут?, и т.п. Те, у которых опыт больше, уже успели сформировать для себя некоторый словарь (переменные цикла называют «i, j, k», одиночный объект «singleton», а метод-конструктор объектов 'somethingFactory'). Впрочем, всегда появляются незнакомые аспекты. Однако, у «начинающих», эта проблема стоит острее. Я думаю, многие, на этом этапе пытались искать спасение в книжках по паттернам. Не всегда удачно. Дело в том, что паттерны описывают не только слова, но и конкретные архитектурные решения, которые за ними стоят. Ни кто, единожды написав слово singleton, не удержится от того, чтобы закодить и всю остальную атрибутику паттерна: для данного класса, на самом деле, можно будет создать лишь единственный экземпляр в рамках всего приложения. Но если, по задумке архитектора, требуется не это (а, например, иметь единственный инстанс лишь в пределах какого-то модуля, не всего приложения)? Проблема. Собственно, причина очевидна: кодер имеет дело лишь с маленьким кусочком решения задачи, и из него совершенно не ясно, какую роль этот код будет играть в архитектуре всего приложения. Все равно, что имея описание кирпича пытаться вообразить себе будущее строение. Кодинг это не тот этап, где можно принимать архитектурные решения. И это не тот этап, где ввод паттернов проектирования будет осмысленным. Именно поэтому выбор паттернов на этом этапе часто оказывается неправильным.
Алгебраически, идентификаторы — самостоятельный тип данных, не похожий на [int]. Идентификаторы бессмысленно делить, умножать, возводить в степень, и делать с ними еще много других операций, которые обычно свойственны целым числам [int]. Идентификаторы можно лишь сравнивать между собой. Множество допустимых значений идентификаторов пользователя конечно — оно определяется множеством значений, заданных в соответствующей таблице БД. В итоге, все эти ограничения формируют тип [user_id]. В строго типизированных языках, переменные так же типизированы. Переменная $user_id будет иметь тип [user_id]. А поскольку в таких языках автоматическое преобразование типов не допускается, то попытка присвоить $user_id = (int) … неизбежно приведет к ошибке. В php'шном синтаксисе подражание строгой типизации выглядит так:
использую строгую типизацию в пхп (вида $user_id = (int) $_GET['user_id'])
Это называется приведением типа. Случись, что php станет строго типизированным, это выражение не скомпилируется, поскольку int и user_id — разные типы данных (у них алгебры разные, скажем, выражение [int] + [int] = [int] законно, а [user_id] + [user_id] не имеет смысла). :)
Насчет зарегистрированных слов — если они Вам мешают и Вы им не пользуетесь, милости просим в те самые файлы с исходниками — все эти слова описаны там и еще легче могут быть оттуда убраны
Мир возможного вообще чудесен. ;) Тем не менее, в реальности, по мере роста версии php, словарь зарезервированных слов языка только расширяется.
Нет. Нельзя. Раздутая грамматика в php это следствие динамической типизации и безумного количества правил приведения типов. В таких языках тип результата определяется не типами аргументов, а типом оператора.
Сравни:
Это не недостаток. Просто особенность данного класса языков — для каждого типа оператора нужна своя «закорючкя». Такие языки не позволяют определять пользовательские операторы. Поэтому обилие встроенных операторов никому не мешает. Чем больше операторов встроено в язык, тем он богаче, однозначнее и лаконичнее. В perl, например, их еще больше. :)
Основной недостаток грамматики php это обилие ключевых слов (зарезервированных). Именно поэтому в классах нельзя называть методы именами 'and', 'or', 'use', 'require' и т.п.
Концептуально, «class» сам по себе образует пространство имен. Для классов есть чудная арифметика, позволяющая эти пространства имен комбинировать — слово extends все знают?… И главное — эти чудеса живут в языке еще со времен PHP4. =)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
Для каких целей создавался «Сервис структур Hivext»?
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
структур позволяет разработчикам создавать свои приложения в стиле ООП, позволяет манипулировать и управлять типами и объектами разрабатываемых приложений
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
По просьбе обчитавшихся верстальщиков, мы сделали наследование шаблонов в смарти-подобном ШД под php.
Но наследование это весьма специфичная штука. В быту, этим словом может обозначаться куча совершенно разных по смыслу понятий:
* обобщение — все страницы которы должны выглядить однообразно, наследуются от общего для них шаблона some_layout.html;
* композиция — в pager.html реализовать блок постраничной листалки и наследовать от него шаблоны, где нужна листалка,
* делегирование — определить блок в шаблоне и рисовать им, или не определять — тогда пусть рисует блок из родительского шаблона
* и т.д.Н
Неподготовленные люди воспринимают наследование, как универсальный инструмент, типа серебряной пули…, даже не так — типа серебряной термоядерной ракеты. Однако, как только кол-во шаблонов в проекте перерастает учебные объемы, то состояние аффекта у них быстро проходит. А на смену ему приходит ужас, поскольку они осознают, что больше не в состоянии контролировать эффекты, создаваемые «иерархиями» шаблонов в несколько этажей.
В общем, если для формирования «представления» нужна сколь-нибудь продвинутая «логика», то лучше этой «логикой» озадачивать программистов. Ну а у них для этого есть отдельный от ШД-«представления» инструментарий. ㋡
кстати, можно задать еще один вопрос про статью? ;)
в части «Общий контент» Вы предложили формат и набор процедур для сохранения мультиязычных данных в общем поле БД. Почему не используете стандартные serialize()/unserialize()? На первый взгляд это было бы проще.
Вы упорно не приводите примеров и я продолжаю непонимать. ㋡
Возможно вот где проблема. Для выборки мультиязычных данных может применяться еще одно правило: «отдавать контент на языке Ⓐ, а если его нет, — на языке оригинала», где язык оригинала это тот, на котором была изначально написана контентина. Тогда версии на всех остальных языках это переводы. А перевод уже _зависят_ от оригинального текста. Наличие такой зависимости влияет на структуру БД.
Для реализации этой идеи на основе Вашего примера, в таблицу news нужно добавить поле news_orig_lang (язык, на котором была изначально написана новость).
Тогда запрос вида: вытащить «перевод» и оригинал будет выглядить так:
SELECT * news_id N
INNER JOIN news_contents NC ON N.news_id = NC.news_id AND NC.lang = N.news_orig_lang
LEFT JOIN news_contents NCtr ON N.news_id = NCtr.news_id AND NCtr.lang = ?userUILang
т.е. через INNER JOIN цепляется язык оригинала, а через LEFT JOIN — перевод.
А из базы контент выгребается сразу на двух языках: языке юзера и языке по умолчанию? Т.е. так:
SELECT *
FROM news N
INNER JOIN news_contents NC ON N.news_id = NC.news_id
WHERE NC.news_lang IN (?clientUILang, ?defaultLang)
Мне понравилась идея разбивать таблицы, так что одна будет содержать поля, которые не зависят от языка, а другая — текстовые.
> 1 таблица (table1)
> news_id
> news_start
> news_stop
> news_visible
> 2 таблица (table2)
> news_id – уникальный номер новости из первой таблицы
> news_lang – уникальный двухбуквенный идентификатор языковых данных
> news_subject – тема (заголовок) новости
> news_short – короткая новость на языке с кодом из news_lang
> news_full – полная новость на языке с кодом из news_lang
В своей статье ты определил, что текстовый контент новости уникален для каждого языка. Т.е. между языками он не пересекается. Поэтому чутье подсказывает, что нужно создавать table2_ru, table2_en и т.д. — индексы меньше, поиск быстрее. Но ты предлагаешь переводы хранить в одной таблице. Каков в этом практический смысл?
Техника расщепления приложения на слои описана у Фаулера в Patterns of Enterprise Application Architecture. В двухслойной архитектуре слои называются Client и Server. В трехслойной архитектуре — Presentation, DomainLogic и DataSource. Слоев может быть и больше. Дело не в названиях и их количестве. Суть в том, что на практике бывает полезно, сильно сцепленные куски логики приложения, обосабливать друг от друга (образуя между ними слабые коммуникационные связи). Например, хорошо отделять DomainLogic (логику, ради которой и создается система ⓒ), от прочего, неизбежно сопутствующего барахла, — UI и внешних API приложения с одной стороны, и источников/хранилищ данных с другой.
В большей части интерпретаций, MVC это принцип, который используется для анализа задач, связанных с созданием инструментов пользователя (Tools). С точки зрения MVC, все интересующие программные артефакты рассматриваются в аспекте представлений и их преобразований из одного в другое. View отражает представление некоторой артефакта, в терминах пользовательской ментальной модели, Model — представление в терминах программной модели, а Controller — представление в терминах управления. Например, инструмент для рейтингования этого коммента, с точки зрения MVC может рассматриваться следующим образом. Для юзера это изображение двух изумительных квадратиков: красного и зеленого — которые символизируют критику и одобрение. Для хабрасервера это строка из набора {'minus','plus'}. Для браузера — два мышекликабельных объекта.
И то и другое, в общем-то, являются самостоятельными концепциями, и не зависят от ООП.
На этапе анализа задачи то и дело возникает проблема идентификации сущностей и отношений между ними. Идентифицировать — значит выделить характерные особенности и придумать уникальное название. На «выходе» должен получиться этакий словарь терминов, наделенных определенным смыслом, при помощи которых, в дальнейшем, будет описываться все решение и составляться программная модель. Классно, если полученная модель будет не только описывать требуемые аспекты задачи, но и — хорошо вписываться в архитектурные решения любимой программной платформы, а так же будет понятна всем членам команды. Т.е. термины должны быть не абы-какими, а общеупотребимыми. Я думаю, что многие и на этом этапе начинают искать спасение в книжках по паттернам проектирования. Вам требуется создать приложение, которое будет взаимодействовать с пользователем? Смотрим книжку, вот и ответ: ModelViewController — всего три слова! Это элементарно и понятно даже «новичку». Значит нужно использовать паттерн MVC. Теперь сравните — MVC в Smaltalk, MVC в .Net.MVC и MVC во фреймворке symfony для php — за тремя одинаковыми словами скрываются четыре совершенно разных архитектурных решения (первое было в книжке). А что в вашей архитектуре будут означать слова ModelViewController? =)
Все программисты, во время кодинга, сталкиваются с проблемой именования сущностей: как назвать класс?, как назвать метод?, как назвать атрибут?, и т.п. Те, у которых опыт больше, уже успели сформировать для себя некоторый словарь (переменные цикла называют «i, j, k», одиночный объект «singleton», а метод-конструктор объектов 'somethingFactory'). Впрочем, всегда появляются незнакомые аспекты. Однако, у «начинающих», эта проблема стоит острее. Я думаю, многие, на этом этапе пытались искать спасение в книжках по паттернам. Не всегда удачно. Дело в том, что паттерны описывают не только слова, но и конкретные архитектурные решения, которые за ними стоят. Ни кто, единожды написав слово singleton, не удержится от того, чтобы закодить и всю остальную атрибутику паттерна: для данного класса, на самом деле, можно будет создать лишь единственный экземпляр в рамках всего приложения. Но если, по задумке архитектора, требуется не это (а, например, иметь единственный инстанс лишь в пределах какого-то модуля, не всего приложения)? Проблема. Собственно, причина очевидна: кодер имеет дело лишь с маленьким кусочком решения задачи, и из него совершенно не ясно, какую роль этот код будет играть в архитектуре всего приложения. Все равно, что имея описание кирпича пытаться вообразить себе будущее строение. Кодинг это не тот этап, где можно принимать архитектурные решения. И это не тот этап, где ввод паттернов проектирования будет осмысленным. Именно поэтому выбор паттернов на этом этапе часто оказывается неправильным.
Мир возможного вообще чудесен. ;) Тем не менее, в реальности, по мере роста версии php, словарь зарезервированных слов языка только расширяется.
Нет. Нельзя. Раздутая грамматика в php это следствие динамической типизации и безумного количества правил приведения типов. В таких языках тип результата определяется не типами аргументов, а типом оператора.
Сравни:
Это не недостаток. Просто особенность данного класса языков — для каждого типа оператора нужна своя «закорючкя». Такие языки не позволяют определять пользовательские операторы. Поэтому обилие встроенных операторов никому не мешает. Чем больше операторов встроено в язык, тем он богаче, однозначнее и лаконичнее. В perl, например, их еще больше. :)
Основной недостаток грамматики php это обилие ключевых слов (зарезервированных). Именно поэтому в классах нельзя называть методы именами 'and', 'or', 'use', 'require' и т.п.
с опытом это пройдет. =)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
Но наследование это весьма специфичная штука. В быту, этим словом может обозначаться куча совершенно разных по смыслу понятий:
* обобщение — все страницы которы должны выглядить однообразно, наследуются от общего для них шаблона some_layout.html;
* композиция — в pager.html реализовать блок постраничной листалки и наследовать от него шаблоны, где нужна листалка,
* делегирование — определить блок в шаблоне и рисовать им, или не определять — тогда пусть рисует блок из родительского шаблона
* и т.д.Н
Неподготовленные люди воспринимают наследование, как универсальный инструмент, типа серебряной пули…, даже не так — типа серебряной термоядерной ракеты. Однако, как только кол-во шаблонов в проекте перерастает учебные объемы, то состояние аффекта у них быстро проходит. А на смену ему приходит ужас, поскольку они осознают, что больше не в состоянии контролировать эффекты, создаваемые «иерархиями» шаблонов в несколько этажей.
В общем, если для формирования «представления» нужна сколь-нибудь продвинутая «логика», то лучше этой «логикой» озадачивать программистов. Ну а у них для этого есть отдельный от ШД-«представления» инструментарий. ㋡
в части «Общий контент» Вы предложили формат и набор процедур для сохранения мультиязычных данных в общем поле БД. Почему не используете стандартные serialize()/unserialize()? На первый взгляд это было бы проще.
Возможно вот где проблема. Для выборки мультиязычных данных может применяться еще одно правило: «отдавать контент на языке Ⓐ, а если его нет, — на языке оригинала», где язык оригинала это тот, на котором была изначально написана контентина. Тогда версии на всех остальных языках это переводы. А перевод уже _зависят_ от оригинального текста. Наличие такой зависимости влияет на структуру БД.
Для реализации этой идеи на основе Вашего примера, в таблицу news нужно добавить поле news_orig_lang (язык, на котором была изначально написана новость).
news:
news_id, news_orig_lang, news_start, …
news_content:
news_id, news_lang, news_subject, …
Тогда запрос вида: вытащить «перевод» и оригинал будет выглядить так:
SELECT * news_id N
INNER JOIN news_contents NC ON N.news_id = NC.news_id AND NC.lang = N.news_orig_lang
LEFT JOIN news_contents NCtr ON N.news_id = NCtr.news_id AND NCtr.lang = ?userUILang
т.е. через INNER JOIN цепляется язык оригинала, а через LEFT JOIN — перевод.
SELECT *
FROM news N
INNER JOIN news_contents NC ON N.news_id = NC.news_id
WHERE NC.news_lang IN (?clientUILang, ?defaultLang)
> 1 таблица (table1)
> news_id
> news_start
> news_stop
> news_visible
> 2 таблица (table2)
> news_id – уникальный номер новости из первой таблицы
> news_lang – уникальный двухбуквенный идентификатор языковых данных
> news_subject – тема (заголовок) новости
> news_short – короткая новость на языке с кодом из news_lang
> news_full – полная новость на языке с кодом из news_lang
В своей статье ты определил, что текстовый контент новости уникален для каждого языка. Т.е. между языками он не пересекается. Поэтому чутье подсказывает, что нужно создавать table2_ru, table2_en и т.д. — индексы меньше, поиск быстрее. Но ты предлагаешь переводы хранить в одной таблице. Каков в этом практический смысл?