«проиграть вживую» — это не спроектировать архитектуру, это, я бы сказал, «из другой оперы». Если «со словорем», а выгода от UML есть, то нужно научить такого человека читать без словаря.
про up2date — я имея ввиду доскональную синхронизацию — название методов, свойств и т.п. Если UML меняется настолько, что в конце проекта не соответсвует действительности, то нужно что-то исправлять в процессе. Видимо, этап проектирования вам не нужен.
а) б) в), мне кажется, получается, если пере-недо-оценивать UML. Тоесть когда важность UML завышается или занижается. Я счетаю, что моделировать нужно до того состояния, пока каждый человек, учавствующий в разработке системы, не будет чётко понимать, как всё работает. После этого с моделями нужно завязывать. Можно распечатать на бумаге. Все пометки\изменения можно делать прямо на бумаге карандашом ( если нужно) вот тогда будет толк. Постоянно деражть UML модель up2date — ошибка и пустая трата времени (по крайней мере пока речь не идёт о системе управления АЭС)
второй вариант. вообще опрос немного некорректный, я уже сам разобрался (прямо как в анекдоте). Я хотел спросить — используете ли Business Objects или Technology-based objects. Тоесть оттталкиваетесь от домена(отрасли), для которого приложение разрабатывается, или от технологии, которая применяется.
Я понял, что Вам не понравилось название. Тем не менее, большенство людей понимают, что я спрашиваю, отвечают на вопрос и я получаю нужную мне информацию.
Да, вопрос заключается именно в этом: «Что представляют из себя модели в Вашем ORM-приложении?»
Моё мнение — что реализация «class User extends DbRow {» ущербнее «class User {». В любом случае.
Хочу «прощупать почву» и поделиться мыслями об этом в следующем топике.
Если (1), то в коде вряд ли появятся классы например, ServerRequest, FileResizer, Form и т.п. очень часто приходиться видеть код, глядя на который кажется, что программист руководствуется простым правилом: если нельзя «положить в базу» — класс создавать незачем. Очень хрчется разобраться в этой теме.
Пример с News — всего лишь пример. Хотел попроще, да видно перестарался.
Один из ключевых моментов сдесь — т.н. контекст, и то что он может быть вложенным, а не сам параметр, поэтому «стратегия» не подходит, по карйней мере «в чистом виде»
т.е. я устанавливаю параметр для «всего, что внутри News cut=true» в одном месте программы, после этого, находясь в контексте «News» у параметра cut будет значение true. Если где-то «дальше» я установлю для этого параметра другое значение в дроугом контексте, допустим «News/NewsPost cut=false» то в «News» он по-прежнему останется «true» а в NewsPost, NewsPostBody будет иметь значение false.
Опять же, более реальный пример с результатами поиска: я не хочу врезультатх поиска полную карточку товара со всеми полями, поэтому устанавливаю «Product/Profile:fieldsetMode=short» когда Profile формирует массив с полями он проверят значение fieldsetMode и соответсвенно возвращает «сокращенный» набор.
короче говоря — это не стратегия. Что-то вроде набора значений в определенном namesapce, который может быть вложенным.
«ограничивать статью» наверное плохой пример, слишком простой… чаще всего это используется, если надо, например, вывести список товаров (релузьтаты поиска). В этом случае не нужно «выдавать» шаблонизатору всю карточку товара целиком (все поля) — при 100 результатах на странице может быть переполнение памяти.
про 10 запросов… да, именно так — на странице может быть больше сотни запросов. Чаще всего разница в скорости небольшая, но если требуется, то оптимизация не больно хитрая — очень неплохо спасает memcached и тонкая настройка MySQL сервера.
Ради чего?.. Ради качества кода. Код получается очень гибкийи понятный.
1. решение не подходит по техническим спецификациям. «мастера» быть не должно по требованиям
2. координатора нет, и взаимодействие с БД на низком уровне исключено, это тоже в технических требованиях. (базы данных потенциально могут находится на разных хостингах, доступ извне закрыт)
Вы, видимо, ошиблись немного веткой. Это решение исключительно для PHP. Не могу сказать (сокрее даже нет), что этот подход приемлем для .NET или Java. Предложенная мною схема приемлема. Работает. Если Вы не можете предложить решение лучшее, и не можете привести доводы, почему моя схема неприемлема, счетаю нашу дискуссию бессмысленной.
Если вы грамотно добавите список минских автошкол, то, возможно, пользователи будут попадать на ваш сайт ещё до того, как сядут за руль (с поисковиков). А замечательное доменное имя 60.by должно им запомниться, как мне кажется.
«Хочу сдать на права… ищу список школ… попадаю на 60.by.» В байнете, по-моему, этого можно добиться.
Двухфазная фиксация в моей схеме (см. диаграмму): каждый клон «рапортует» о том, что у него «всё в порядке» — утсанавливается статус «READY» который могут «прочитать» все клоны. После этого каждый клон ожидает статуса «READY» на всех других клонах. И после этого делает COMMIT БД. Это как-раз-таки и показано у меня на схеме. Возможно, вы говорите о «истинной двуфазной транзакции» (на уровне базы данных). Так у меня этого нет, я не спорю. Но это без проблем впишется в мою «схему» при необходимости.
Я упрошённо показал схему. На деле, конечно, всё дорабатывается, всех деталей я не отображал — схема получилась бы слишком сложной.
хороший архитектор должен быть готов к этому
про up2date — я имея ввиду доскональную синхронизацию — название методов, свойств и т.п. Если UML меняется настолько, что в конце проекта не соответсвует действительности, то нужно что-то исправлять в процессе. Видимо, этап проектирования вам не нужен.
Да, вопрос заключается именно в этом: «Что представляют из себя модели в Вашем ORM-приложении?»
Моё мнение — что реализация «class User extends DbRow {» ущербнее «class User {». В любом случае.
Хочу «прощупать почву» и поделиться мыслями об этом в следующем топике.
специально для Вас, более «профессиональный» вопрос:
Характерно ли для Вашего кода такое:
class User extends DbRow {…
Один из ключевых моментов сдесь — т.н. контекст, и то что он может быть вложенным, а не сам параметр, поэтому «стратегия» не подходит, по карйней мере «в чистом виде»
т.е. я устанавливаю параметр для «всего, что внутри News cut=true» в одном месте программы, после этого, находясь в контексте «News» у параметра cut будет значение true. Если где-то «дальше» я установлю для этого параметра другое значение в дроугом контексте, допустим «News/NewsPost cut=false» то в «News» он по-прежнему останется «true» а в NewsPost, NewsPostBody будет иметь значение false.
Опять же, более реальный пример с результатами поиска: я не хочу врезультатх поиска полную карточку товара со всеми полями, поэтому устанавливаю «Product/Profile:fieldsetMode=short» когда Profile формирует массив с полями он проверят значение fieldsetMode и соответсвенно возвращает «сокращенный» набор.
короче говоря — это не стратегия. Что-то вроде набора значений в определенном namesapce, который может быть вложенным.
про 10 запросов… да, именно так — на странице может быть больше сотни запросов. Чаще всего разница в скорости небольшая, но если требуется, то оптимизация не больно хитрая — очень неплохо спасает memcached и тонкая настройка MySQL сервера.
Ради чего?.. Ради качества кода. Код получается очень гибкийи понятный.
2. координатора нет, и взаимодействие с БД на низком уровне исключено, это тоже в технических требованиях. (базы данных потенциально могут находится на разных хостингах, доступ извне закрыт)
Вы, видимо, ошиблись немного веткой. Это решение исключительно для PHP. Не могу сказать (сокрее даже нет), что этот подход приемлем для .NET или Java. Предложенная мною схема приемлема. Работает. Если Вы не можете предложить решение лучшее, и не можете привести доводы, почему моя схема неприемлема, счетаю нашу дискуссию бессмысленной.
«Хочу сдать на права… ищу список школ… попадаю на 60.by.» В байнете, по-моему, этого можно добиться.
Удачи!
Я упрошённо показал схему. На деле, конечно, всё дорабатывается, всех деталей я не отображал — схема получилась бы слишком сложной.