Допустим, что есть некая архитектура, в которой пять слоёв:
1) уровень работы с кодировками текста и форматами файлов
2) уровень текстовых операций редактора текстов (добавить отступ для группы строк)
3) уровень элементов и атрибутов xml-формата
4) уровень объектов абстрактного проекта msbuild
5) уровень объектов C# программы в формате .csproj
В каждом слое есть своё API, свои наборы операций, свои структуры данных и константы.
Если хочется иметь полный контроль над всем,
но при этом не давать доступ к нижним уровням на прямую,
то каждый более высокий оказывается объёмнее предыдущего (так как включает всё что уже есть ниже, но по-своему).
Идея такова — разрешить пользоваться API всех уровней, а не только непосредственно нижележащего.
Для того, чтобы при работе с элементами нижнего уровня можно было
делать что-то осмысленное с верхнего уровня должен быть виден контекст,
то есть связи между элементами объектных моделей разных уровней должны быть двухсторонними.
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>Дальше мысль не идёт.
Прочитать FDG (доступна в safari books, триала на 10 дней должно хватить). Обязательная штука для человека, который хочет заниматься проектированием API под .net (да и не только под .net).) + architecture guidelines book. В последней вас интересует общий подход, расписан в Chapter 5: Layered Application Guidelines, в первой — умение думать правильно и отлавливать ошибки в рассуждениях до того, как они повлияют на дизайн API.
У вас проблема не в собственно разделении на слои, а в том, что вы пытаетесь это сделать, пропустив все предыдущие этапы, от case study и до выяснения ключевых ответственностей.
Ну и естессно, получается, что "каждый более высокий оказывается объёмнее предыдущего (так как включает всё что уже есть ниже, но по-своему)".
Я просмотрел (не подробно прочитал на запоминание, но всё-таки) советуемое, но не проникся.
Первая предложенная книжка хороша в корпоративных политических войнах,
когда нужно задавить авторитетом — делаем так, потому что так сказано в FDG.
Но не зажигает, ясностью не наполняет.
Видимо мне нужно прочитать дополнительно что-то другое.
S>вы пытаетесь это сделать, пропустив все предыдущие этапы, от case study и до выяснения ключевых ответственностей.
Этапы есть только во втором, но упора на "ответственности" там нет.
Вы что-то такое прочитали про "Key Responsibilities", что Вам очень понравилось, а я не читал.
Здравствуйте, Arsen.Shnurkov, Вы писали:
S>>У вас проблема
AS>Я просмотрел (не подробно прочитал на запоминание, но всё-таки) советуемое, но не проникся.
Ага, если пролистывать, то как обычный справочник выглядит.
Там вся ценность — не в собственно в правилах, а в подходе к дизайну API и в пояснениях. Как думают товарищи авторы, что для них важно в дизайне API, что нет.
Вдохновлять оно и не должно, но от стандартных проблем типа "дизайним _до_ того, как представляем, как оно будет использоваться" лечит неплохо
AS>Этапы есть только во втором, но упора на "ответственности" там нет. AS>Вы что-то такое прочитали про "Key Responsibilities", что Вам очень понравилось, а я не читал.
Неа, это уже из опыта. Нет никакого смысла разделять код на слои до тех пор, пока вы не определитесь с ответственностями для каждого из слоёв.
Классический простой пример — работа с XML. Для большинства пользователей достаточно XDocument.Load("SomeFile"), но все остальные сценарии (вплоть до откровенных извращений типа подмены имени кодировки) выполняются через перегрузки одного и того же метода.
В результате с одной стороны — довольно интуитивный код и никакого сфероконизма типа abstractPatternFacadeSingletonFactoryБлаБла (подобного в дотнете вообще не встречается, за этим — к яве).
С другой — под капотом там настоящий слоёный пирог — чтение из потока, чтение текстового потока, токенизация, разбор xml, валидация (ага, мало кто знает, но оно есть) и тыды и тыпы.
С третьей — одна и та же инфраструктура (XmlReader) _без_ изменений переиспользуется как минимум в трёх фреймворках по работе с XML (XmlDocument, XDocument, DataCOntractSerializer), а в последнем — ещё и расширяется кастомными классами (XmlDictionaryReader и наследники). И работает без особых изменений в public api начиная с первого фреймворка. 15 лет спустя, ага.
Вот это я называю дизайном здорового человека. Если вдуматься — внушает. Особенно если учесть, что формальных слоёв тут нет (скажем, стек xmlReader и стек xmlWriter друг с другом связаны разве что общим стилем), код отлично работает при использовании функционала с разных слоёв и при этом использование "высокоуровневого" кода остаётся вполне удобным.
Возвращаясь к теме — удачный дизайн не по наитию получается. И не как результат попыток сделать всемогутор (скорее наоборот, ни одного удачного не видел). А как результат "находим основные сценарии использования, думаем, как сделать public api с минимумом WTF moments, делаем".
Аналогичный подход работает не только с конкретными типами, но и с инфраструктурой в целом. Только количество сценариев использования заметно больше выходит. Поэтому как правило сначала вчерновую собирают примеры того функционала, который нужно реализовать, а затем уже раскидывают ответственности по слоям, используя простой принцип "ничего не знает о". Ну, т.е. Stream отлично компилируется и работает без StreamReader, StreamReader знает о существовании Stream, но не догадывается о XmlReader и тыды и тыпы.
Получается, что каждый из слоёв по умолчанию использует public API предыдущего слоя _и_ каждый слой позволяет при необходимости подкрутить логику нижележащих слоёв, например, передавая правильно настроенный объект. И для дизайна многослойного API нужно
* уметь дизайнить public API каждого из слоёв.
* суметь разнести ответственности так, чтобы каждый из слоёв не был задизайнен исключительно под нужды следующих.
S>Вот это я называю дизайном здорового человека. Если вдуматься — внушает. Особенно если учесть, что формальных слоёв тут нет (скажем, стек xmlReader и стек xmlWriter друг с другом связаны разве что общим стилем), код отлично работает при использовании функционала с разных слоёв и при этом использование "высокоуровневого" кода остаётся вполне удобным.
S>Возвращаясь к теме — удачный дизайн не по наитию получается. И не как результат попыток сделать всемогутор (скорее наоборот, ни одного удачного не видел). А как результат "находим основные сценарии использования, думаем, как сделать public api с минимумом WTF moments, делаем".
А вот не рановато ли думать о public api до создания самой архитектуры? На мой взгляд, API тогда удачно получаются, когда продиктованы архитектурой, а не наоборот. Т.е. строим дом, потом врезаем окна, а не под сущ. окна строим дом.
На счет fdg я бы поспорил, т.к. интереснее, что читали сами авторы, ибо с первого раза спроетировать api на 15 лет это реально круто. Думается мне с математикой они дружили. Очень интересна с этой точки зрения книга Степанова "Elements of programming". Она вышла позже, но крайне любопытна и полезна ибо при дизайне чего-либо (архитектуры, api) советует смотреть на математику: архитектура должна быть похожа на построение доказательств в математике, только в обратную сторону. Т.е. есть ядро архитектуры (аксиомы), далее создается соотв. функционал (теоремы, леммы). Теорема 1 исп. в теореме 2 и т.д.
Здравствуйте, Sharov, Вы писали:
S>А вот не рановато ли думать о public api до создания самой архитектуры? На мой взгляд, API тогда удачно получаются, когда продиктованы архитектурой, а не наоборот.
Как показывает практика — не рано, если говорить об инфраструктуре, для которой сценарии использования очевидны.
Тут важно само наличие формализованного public api, а не его качество, т.к. мы на самом раннем этапе получаем:
1. Набор ключевых сценариев для фреймворка.
2. Код с примерами использования этих сценариев, он же — готовые интеграционные тесты
3. Возможность проверить архитектуру на адекватность требованиям.
Т.е. на этом этапе public API играет роль спецификации/требований, с учётом которых строится архитектура и пишется реальный код.
В результате мы имеем адекватное представление о проекте в целом буквально с нулевого дня. В твоей аналогии
Т.е. строим дом, потом врезаем окна, а не под сущ. окна строим дом.
делаем модельку, которая прописывает уровень освещённости, вентиляцию и что там ещё по санпину и в процессе собственно проектирования дома постоянно проверяем, что мы в эти требования укладываемся. В общем, речь про подсобный инструмент, а не про замену собственно проектированию.
upd хо, я даже сделал про это оговорку в предыдущем посте. Всё ок короче.
Аналогичный подход работает не только с конкретными типами, но и с инфраструктурой в целом. Только количество сценариев использования заметно больше выходит. Поэтому как правило сначала вчерновую собирают примеры того функционала, который нужно реализовать, а затем уже раскидывают ответственности по слоям, используя простой принцип "ничего не знает о". Ну, т.е. Stream отлично компилируется и работает без StreamReader, StreamReader знает о существовании Stream, но не догадывается о XmlReader и тыды и тыпы.
Как раз на этой идее про постоянную проверку практикой aka
Framework Design Principle
Frameworks must be designed starting from a set of usage scenarios and code samples implementing these scenarios.
вся FDG и построена
S>На счет fdg я бы поспорил, т.к. интереснее, что читали сами авторы, ибо с первого раза спроетировать api на 15 лет это реально круто. Думается мне с математикой они дружили. Очень интересна с этой точки зрения книга Степанова "Elements of programming".
Ну это безусловно да. Проблема в том, что даже FDG осиливают единицы. Поэтому сначала ползать, затем летать
Здравствуйте, Sinix, Вы писали:
S>>На счет fdg я бы поспорил, т.к. интереснее, что читали сами авторы, ибо с первого раза спроетировать api на 15 лет это реально круто. Думается мне с математикой они дружили. Очень интересна с этой точки зрения книга Степанова "Elements of programming". S>Ну это безусловно да. Проблема в том, что даже FDG осиливают единицы. Поэтому сначала ползать, затем летать
Все, что Вы пишете безусловно верно применительно к созданию фреймворка, т.е. набора неких публичных библиотек. Безусловно там надо плясать от public api, но вот, допустим, ТС пишет сугубо утилитарное приложение для своей компании или группы пользователей. Т.е. ни о каких публичных библиотеках речи не идет, конечный продукт. Зачем ему читать fdg? Да для общего развития, да там есть хорошие идеи и замечания, но эта книга вряд ли будет полезной для решения конкретно поставленной задачи. Степанов то с его подходом как раз и будет про "ползать", а fdg уже "летать".
ЗЫ: И все-таки говорить, что парне из мс вот прям молодцы-молодцы тоже не очень справедливо. Ребята не на ровном месте и с нуля все придумывали, а оглядывались (подглядывали) на мир java.
Здравствуйте, Sharov, Вы писали:
S>Зачем ему читать fdg?
Ну блин, это ж очевидно. Ни один софт не является однородной мешаниной из методов и типов, внутри точно так же присутствует разделение на подсистемы-слои-компоненты-хелперы.
Не, в маленьком софте, который разрабатывается парой-тройкой девелоперов ещё можно лениться и развести бардак.
А в средних и уж тем более в крупных проектах любой компонент, которым ваша команда не владеет, вы можете использовать только через его API. Залезая в внутренности напрямую вы неминуемо испортите жизнь всем — от собственно разработчиков, которые теперь не могут чинить ошибки, не сломав ваш код и до других команд, чьи сценарии легко могли поломаться от ваших изменений.
Ну а дальше есть всего два варианта. Или внутреннее API пишется от балды, или учим FDG. Проверено неоднократно, причём сложным способом. В одном из проектов за системную часть и биз-код отвечали две команды, причём общение между ними наладить толком никто не озаботился. В итоге уже через год-полтора 90% системного API было спрятано под хелперами, разработанными второй командой. Потому что всё было в принципе задизайнено правильно, но не было бы ни одного сценария (я серьёзно, от запросов и до создания бизнес-сущностей), который не требовал бы минимум двух-трёх вызовов методов. Не, в итоге получилось даже неплохо, но изначально количество строк, ублажавших инфраструктуру было раз в 5 больше, чем собственно бизнес-логики. Вот такой вот высокоуровневый ассемблер
S>ЗЫ: И все-таки говорить, что парне из мс вот прям молодцы-молодцы тоже не очень справедливо. Ребята не на ровном месте и с нуля все придумывали, а оглядывались (подглядывали) на мир java.
Ну да, согласен абсолютно. Один нюанс: ява — это как раз отличный пример "точно такого же, только без FDG". Серьёзно, фреймворк, который для части элементарщины типа чтения xml требует приседаний в духе
а остальную часть вообще лучше сторонними библиотеками заменить (не будем показывать пальцем, но это был Runtime.exec(). jproc, ещё раз спасибо).
никак не назовёшь вершиной дизайна
Про перевод Document в строку — давайте не будем. doc.toString() — недостаточно энтерпрайзненько.
P.S. Очень-очень подозреваю, что у команды инфраструктурщиков из того проекта за плечами была в основном ява
Здравствуйте, Sinix, Вы писали:
S>>ЗЫ: И все-таки говорить, что парне из мс вот прям молодцы-молодцы тоже не очень справедливо. Ребята не на ровном месте и с нуля все придумывали, а оглядывались (подглядывали) на мир java.
S>Ну да, согласен абсолютно. Один нюанс: ява — это как раз отличный пример "точно такого же, только без FDG". Серьёзно, фреймворк, который для части элементарщины типа чтения xml требует приседаний в духе S>
fdg тогда не было, но вот gof уже начали творить. И в коде выше (да судя по всему и во всей jdk) чувствуется их влияние. А посмотреть на неправильное решение тоже бывает крайне полезно. Как не надо делать почти пол дела.
1) архитектура это сложно-сложно, не лезьте сюда, у нас тут и математики и социология и вообще самим работы не хватает.
2) тысячи классов это нормально, всё равно как уменьшить сложность мы не знаем.
и .Net Framework с его циклическими зависимостями между assemblies — это да, пример для подражания...
3) разрабатывать архитектуры мы не умеем, можем только по тестовым использованиям сказать — удачно вышло или не очень.
кто умел разрабатывать, так это Страуструп, с его CRC-карточками, метод, который никто не вспомнил
но этому итак в русской культуре с детства учат, показывая игру в подкидного дурака с разными возможностями разных персон
Здравствуйте, Arsen.Shnurkov, Вы писали:
AS>В каждом слое есть своё API, свои наборы операций, свои структуры данных и константы.
AS>Если хочется иметь полный контроль над всем, AS>но при этом не давать доступ к нижним уровням на прямую, AS>то каждый более высокий оказывается объёмнее предыдущего (так как включает всё что уже есть ниже, но по-своему).
Ну сделайте на верхнем уровне возможность работать с готовыми объектами из уровня ниже. Тогда пользователь всего это API сможет, если захочет, в проект csproj другой форматировщик для отступов, который создаст заранее сам. Все вменяемые библиотеки так устроены.
В чём вообще вопрос? Как ковыряться в xml? Ну способов 10 разных точно есть. По ссылке какая-то тривиальная ерунда, XSLT задействуй, если файлы переписывать хочется. А в рамках идеологии MSBuild вообще решается через переменные (<PropertyGroup/>) и условные выражения в таргетах — подставляешь в нужных местах переменные и меняешь их значения в зависимости от каких-то условий.
Вот пример из CSPROJ — генерация разных подключений к бд в зависимости от выбранной конфигурации (переменная Configuration):
<UsingTask TaskName="TransformXml" AssemblyFile="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Web\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterBuild" Condition="Exists('ConnectionStrings.$(Configuration).config')">
<!--Generate transformed config in the project directory, because Web apps pick files from there-->
<TransformXml Source="ConnectionStrings.config" Destination="ConnectionStrings.config" Transform="ConnectionStrings.$(Configuration).config" />
</Target>
Здравствуйте, Arsen.Shnurkov, Вы писали:
V>>>> Все вменяемые библиотеки так устроены. AS>>> Покажите мне это на примере Roslyn V>> В чём вообще вопрос?
AS>Рослин устроен не так.
Рослин — это компилятор в дотнетовский байт-код, а вопросы касались XML для файлов проектов, не исходного кода. AS>Нельзя управлять с уровня приложения тем, как будут отформатированы пробелы.
Рослин помогает генерировать код, пробелы и отступы в котором именно такие, какие установил пользователь сам для себя. Rак они это делают не выяснял, но это самый разумный подход — я как пользователь лучше знаю какие пробелы и отступы мне нужны в моём коде. AS>Вы, например, не справились.
Я не волшебник, я только учусь.
AS>А это передовейший проект, написанный архитектурнейшими архитекторами.
Вы определитесь с проектом: https://github.com/dotnet/roslyn https://github.com/Microsoft/msbuild
Здравствуйте, Vladek, Вы писали:
V>Вы определитесь с проектом:
Не, топикстартер в принципе почти по адресу вопросы задаёт, roslyn project system — это будущее API для работы с проектами в следующей студии / VS Code. Один подвох: на сегодня это не public API, оно не закончено и оно не рассчитано на работу в отрыве от хоста.
В теории надо исходную задачу озвучить, с вероятностью процентов в 80 там даже код писать не потребуется. Но учитывая, что ув Arsen.Shnurkov умудряется фразы
речь про подсобный инструмент, а не про замену собственно проектированию.
воспринимать как
разрабатывать архитектуры мы не умеем, можем только по тестовым использованиям сказать — удачно вышло или не очень
а вы почитайте доку на msbuild, он не работает с конкретными видами проектов, только с обобщёнными MsBuild Item
S> я могу только помахать рукой и пожелать удачи
я так и сказал. Могли бы что-то ещё, дали бы ссылку на книжку с методикой.
Угу. И ещё надо учитывать, что помимо csproj нужны sln , т.к. в них прописывается порядок сборки (отдельные гении добавляют ссылки на сборки не как project reference, а как ссылку на собранную библиотеку в общей папке bin).
Кроме того нужно учитывать conditional build symbols, всевозможные извращения в виде targets include а также мегатонны приседаний с ссылками на библиотеки из нюгета с адскими хаками в виде перенаправления версий через app.config.
В общем тут всё очень печально и очень сильно завязано на легаси, чтоб делать что-либо с наскока. Особенно если не дай бог речь про мерж нескольких солюшнов. В общем случае только застрелиться можно.
Если речь про утилиту под себя, то я бы решил дело простым парсером sln + csproj-файлов. Делал такое несколько десятков раз, наколеночный вариант обычно укладывается в 1k строк, редко больше.
Если речь про универсальную утилиту — нужно знать, какую проблему вы пытаетесь решить. Потому что легко может оказаться так, что изначальные требования типа манипуляций с зависимостями — только вершина айсберга, тут любая мелочь может подкинуть очень неприятные сюрпризы.
S>> я могу только помахать рукой и пожелать удачи AS>я так и сказал. Могли бы что-то ещё, дали бы ссылку на книжку с методикой.
Ну блин, кто ж знал, что спрашивая про "как сделать слоёную архитектуру" вы на самом деле интересовались, как сделать своё API для правки csproj-файлов?
S> нужно знать, какую проблему вы пытаетесь решить
Вы путаетесь. Сначала вы (ссылаясь на FDG) говорили, что при дизайне фреймворка
нужно рассматривать максимально широкий спектр задач потенциальных пользователей.
А теперь говорите — нужна одна конкретная проблема и вообще поменьше усилий, чтобы обойтись одним изменением в отдельном случае.
С таким подходом вас вообще к проектированию фреймворков подпускать нельзя.
S> я бы решил дело простым парсером sln + csproj-файлов.
Это всё равно что сказать, что компилятор только из парсера состоит, а кодогенерация это фигня.
Парсер теряет информацию о положении токенов в тексте и не содержит модели редактирования
(таким образом, нельзя в дальнейшем анализировать последующие операции преобразования с точки зрения минимизации вносимых изменений в исходник .csproj)
Парсер строит AST, а нужно ещё задизайнить объектную модель, при помощи которой можно этим AST манипулировать.
Q) мне нужен фреймворк.
A) ты дурачок, фреймворки это сложно, тебе фреймворк не нужен, есть полно готовых решений (более 10 способов)
Q) фреймворка нет, пруф
A) ну мы бы не парились
).
