First, determine what type of application you are building. Is it a mobile application, a rich client, a rich Internet application, a service, a Web application, or some combination of these types?

выбор поражает воображение

(Reply) (Thread)

>выбор поражает воображение

А что не так?

(Reply) (Parent) (Thread)

компилятор к какому типу отнести? VoD-сервер? любое stand-alone приложение (например, векторный редактор)?

(Reply) (Parent) (Thread)

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

VoD-сервер (не знаю, что это) — это сервис, плюс, возможно, web-приложение.

Векторный редактор — это типичный rich client.

(Reply) (Parent) (Thread)

компилятор может являтся частью большого проекта. очень большого проекта. вполне себе enterprise проекта

VoD = Video On Demand. лпределение этого как "сервис" несколько раздражает - тогда уж любое приложение это "сервис"

каким местом это клиент? клиент в чём? это stand-alone приложение, оно не работает в многозвенке

Edited at 2009-01-23 12:00 pm (UTC)

(Reply) (Parent) (Thread)

>компилятор может являтся частью большого проекта.

Да, например, он может входить в состав IDE, которое является rich client application.

>определение этого как "сервис" несколько раздражает - тогда уж любое приложение это "сервис"

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

>каким местом это клиент?

А что ж ещё? Оно выполняется у клиента локально, в этом смысле оно является клиентским.

>оно не работает в многозвенке

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

(Reply) (Parent) (Thread)

ещё раз - очень притянуто за уши. они сразу выбирают в качестве базиса систему, которая далеко не очевидна

во всяком случае мне не очевидна

(Reply) (Parent) (Thread) (Expand)

или, например, распределённое приложение, контролирующее состояние расчётного кластера

оно не клиент-сервер, оно на равноправных узлах

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

(Reply) (Parent) (Thread)

>или, например, распределённое приложение, контролирующее состояние расчётного кластера

>оно не клиент-сервер

Да, оно не клиент-сервер, это просто сервер.

>оно настолько притянуто за уши, что дальше читать не хочется

Тебе читать дальше не советую. Больно мне нужно доказывать, что App Arch Guide не верблюд.

(Reply) (Parent) (Thread) (Expand)

ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ

(Reply) (Parent) (Thread)

Q>>Векторный редактор — это типичный rich client.

Z>ЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫЫ

App Arch Guide 2.0, стр. 30:
Mobile Application
• Can be developed as a Web application or a rich client application.
• Can support occasionally connected scenarios.
• Runs on devices with limited hardware resources.
Rich Client Application
• Usually developed as a stand-alone application.
• Can support disconnected or occasionally connected scenarios.
• Uses the processing and storage resources of the local machine.
Rich Internet Application
• Can support multiple platforms and browsers.
• Can be deployed over the Internet.
• Designed for rich media and graphical content.
• Runs in the browser sandbox for maximum security.
• Can use the processing and storage resources of the local machine.
Service Application
• Designed to support loose coupling between distributed components.
• Service operations are called using XML-based messages.
• Can be accessed from the local machine or remotely, depending on
the transport protocol.
Web Application
• Can support multiple platforms and browsers.
• Supports only connected scenarios.
• Uses the processing and storage resources of the server.

Насчёт «клиент—сервер» там идёт следующая табличка «Architecture style».

(Reply) (Parent) (Thread)

Опять ООП Головного Мозга? Скучно...

(Reply) (Thread)

это не скучно, это грустно. сначала по таким guidelines пишут какую-нибудь MoCCA (а что, она им удовлетворяет на ура)

а потом внезапно в проекте надо сделать API migration. и у всех полные штаны, и совсем не от счастья

by the way, если хотя бы навигация была выполнена посредством DDD - этой проблемы вообще бы не было. то есть совсем, в принципе - и неважно даже, что будет использоваться в качестве хостового языка

(Reply) (Parent) (Thread)

Не прошло и полгода с тех пор, как этот персонаж узнал про Y-комбинатор, как уже поплёвывает свысока на ООП. «Илитизм» заразен?

(Reply) (Parent) (Thread)

откуда столько святости? :)

и что за чёртово слово "илитизм"? раздражает не меньше Ънтерпрайза, честное слово

(Reply) (Parent) (Thread)

Полгода -- достаточный срок, чтобы изменить мнение. Ах, ну да, тупому быдлу, вроде тебя, не свойственно менятся... Как я мог забыть!

(Reply) (Parent) (Thread)

>тупому быдлу, вроде тебя

Видишь ли, когда хочешь развести знатный срач, делать это надо гораздо тоньше, и ни в коем случае не переходить на ругань в миттельшпиле. При грамотном троллинге вовсе нет нужды срываться на неприкрытое хамство. Если бы я стал отвечать тебе взаимностью, поставил бы в неловкое положение не только себя, но и jtootf'а, который, очевидно, тебя сюда привёл. Он же не предполагал (надеюсь), что ссылка на мой пост в контексте «Гля, как Майкрософт пацану мозги промыл!» послужит тебе императивом прийти и необоснованно оскорбить автора? Самому-то тебе не стыдно?

(Reply) (Parent) (Thread)

нетрезвый он сюда пришёл. к сожалению. вообще рассказать про связку CL + .Net как раз ему есть чего

надеюсь таки расскажет

P.S. и таки да, мне за него тоже стыдно. приношу извинения

(Reply) (Parent) (Thread)

Да и с каких это пор Y-Combinator стал критерием понимания других (по сравнению с ООП) концепций? Что, уважаемое быдло ни о чём, сверх ООП, кроме ФП не слышало?

Можешь не отвечать, и так понятно.

(Reply) (Parent) (Thread)

>Что, уважаемое быдло ни о чём, сверх ООП, кроме ФП не слышало?

Осторожная оговорка «сверх ООП, кроме ФП» улыбнула :)

А вообще, перестань пускать пыль в глаза и намекать на свои тайные знания. Неубедительно у тебя это выходит. Говори по существу, если есть что сказать.

(Reply) (Parent) (Thread)

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

как-нибудь позже предлагаю обсудить сабжевый вопрос в более спокойной обстановке

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

к .Net я отношусь хорошо с точки зрения компиляторостроения: мне очень нравится сама VM; C# (вплоть до последних его версий) и популярные технологии поверх .Net - нет. если в MS сделают что-то вроде Reactive (FRP) или REBOL поверх .Net - будет очень и очень хорошо; WPF/Spec# и прочий bleeding edge меня не впечатлил

Edited at 2009-01-24 02:23 am (UTC)

(Reply) (Thread)

>выбор какого-либо паттерна и какой-либо технологии должен быть следствием таксономии предметной области.

Всё не так однозначно. Приведу один из примеров.

Такие характеристики как плохая-связность (coupling) и хорошая-связность (cohesion) применимы для оценки качества практически любой системы в любой предметной области. Просто из-за того, что выписанные в столбик преимущества слабосвязной архитектуры во многом будут общими не только для приложений из разных domain'ов, но и для приложений из разных классов процитированной тобой топорной классификации (rich client, web, etc). (Эти две классификации, кстати, не являются взаимоисключающими, они скорее ортогональны.)

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

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

И только на этом шаге предлагаются конкретные технологии, тот же Unity. Причём не только от Microsoft. А написать самому подобную штуку весьма непросто.

Ты не притягиваешь к IoC архитектуру, просто используешь его при необходимости на любом уровне, в любой предметной области. IoC не является специфичным для какого-то domain'а, так же как и, например, Dictionary<K, V> или std::vector<T>. И это хорошо.

>всегда лучше написать недостающую часть, чем притягивать архитектуру к существующим решениям

«Решение» в случае того же Unity — это громко сказано. В действительности, это маленький, независимый от domain'а, хорошо конфигурируемый сгусток функционала. В зависимости от твоей предметной области, он может быть и singleton holder'ом, и фабрикой, и просто хранилищем объектов, и при этом справлятся со своей задачей — следить за зависимостями, экранировать части приложения от избыточных связей, улучшать тестируемость.

Так вот, подобное чтиво о конкретных работающих небольших решениях на меня гораздо лучше влияет, чем пространные описания расплывчатых методологий типа TDD, DDD, всяких философов от программирования и бюрократических процессов типа Scrum, Agile, XP, etc.

>WPF/Spec# и прочий bleeding edge меня не впечатлил

Обычно при евангелизме WPF приводят в пример всякий графический буллшит, типа развевающейся от движений мыши простыни, которая работает как TextBox. В действительности, WPF очень удобен для самой будничной работы, не в последнюю очередь из-за того, что большая часть кода декларативна, плюс крайне удобная поддержка привязок (лучше, похоже, только в Adobe Flex).

(Reply) (Parent) (Thread)

Так вот, подобное чтиво о конкретных работающих небольших решениях на меня гораздо лучше влияет, чем пространные описания расплывчатых методологий типа TDD, DDD, всяких философов от программирования и бюрократических процессов типа Scrum, Agile, XP, etc

ну, DDD это не расплывчатая методология :) она применима к любому стилю проектирования - достаточно вместо таксономии области решений (т.е. оптимального выбора готовых средств абстракции - ЯП, фрейморков, etc) строить DSL под каждую подобласть (в соответствии с FAST Вайсса)

и корректней будет сказать не философы, а математики от программирования. формальное описание семантик имеющихся подобластей предметной области (в идеале - по паттерну layers, который в pdf'нике, кстати, рассмотрен) - единственный, в общем-то, путь к оптимальному решению. при формальном проектировании (без использования паттернов) эта методика всё равно применяется последние лет 50, но применяется в большинстве своём интуитивно - на основании накопленного опыта проектировщика. что чревато

к тому же моменту - не увидел в документе пока что никакой связи между архитектурой и control-flow; можешь ткнуть в раздел, который помог бы мне применить эти указания для компонентно-ориентированной системы с асинхронным обменом сообщениями? FSM, сети Петри, пи-исчисление - что предлагается здесь?

В действительности, WPF очень удобен для самой будничной работы, не в последнюю очередь из-за того, что большая часть кода декларативна, плюс крайне удобная поддержка привязок (лучше, похоже, только в Adobe Flex)

этого абзаца вообще не понял. либо понял неверно. пояснишь?

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

(Reply) (Parent) (Thread)

Q>>В действительности, WPF очень удобен для самой будничной работы, не в последнюю очередь из-за того, что большая часть кода декларативна, плюс крайне удобная поддержка привязок (лучше, похоже, только в Adobe Flex)

J>этого абзаца вообще не понял. либо понял неверно. пояснишь?

На эту тему надо отдельный пост накропать.

(Reply) (Parent) (Thread)

ок, я подожду

(Reply) (Parent) (Thread)