Имеется прототип desktop приложения на WinForms, который пришло время начать делать хорошо.
Приложение представляет собой single document-view, по концепции очень похожее на файл проекта Visual Studio: в некоей директории находятся россыпью файлы разных типов, над которыми производятся действия из приложения. Действия достаточно простые, например, если файл является изображением, то отобразить его в окне просмотра и отобразить его свойства (размеры, формат пикселя и т.п.), если звук, то дать возможность воспроизвести, если текстовый файл, то показать содержимое и т.п, плюс дать поредактировать несложную метаинформацию как для каждого файла в отдельности, так и групповым способом (так же, как свойства файлов в VS). В том числе могут быть "композиты" из более чем одного файла, например, изображение и его альфа-канал в отдельном файле, такие файлы желательно показывать, как одну сущность, ну или как-то сгруппированно. Документ представляет собой Xml с описанием этой иерархии и ссылками на реальные файлы и описанием дополнительных атрибутов для них (метаинформация, какие-то действия на основе этой метаинформации, включён в или исключён из проекта).
Какие практики разумно применять при разработке архитектуры подобного приложения применительно к WinForms? В Сети всё либо очень неконкретно (особенно от Microsoft бла-бла-бла), либо мало и не то. Из наиболее подходящего удалось нагуглить OSGi.NET от какого-то китайца, но просмотр внутренностей проекта несколько потрепал чувство прекрасного. Я не участвовал в разработке подобного софта сколько-нибудь серьёзно, поэтому испытываю некоторые, эммм, затруднения , т.к. хочется изначально избежать хотя бы детских ошибок, если всё-таки придётся делать архитектуру самому. Про такие технологии, как DI и IoC слышал, но не более того, также слышал про Prism, Autofuc и Caliburn.Micro, но тоже не более того. В идеале, мне нужно примерно следующее, желательно без лишних сложностей:
* Два вида на форме: левый и правый. Левый показывает иерархию, правый — редактор/просмотрщик для выделенного в иерархии элемента;
* Типы элементов могут добавляться в будущем, и в этом месте нужна расширяемость;
* Групповое редактирование свойств элементов во время множественного выбора в иерархии (тут мне представляется первая сложность);
* Do/Undo для команд редактирования свойств элементов (это вторая сложность);
* Контекстное меню для элементов, которое может наполняться разными командами для разных типов;
* Главное меню и тулбар, куда же без них, с централизованным управлением командами (активна/неактивна и т.п.) по типу Actions;
* Возможность асинхронного выполнения команд, т.к. могут быть очень длительные.
С одной стороны, вроде ничего сложного, а с другой — как ни возьмись, постоянно получается танк Мне было бы достаточно только разобраться на уровне интерфейсов (ну, там всякие IShell, IView, ICommand и пр.) что с чем и как должно взаимодействовать, чтобы было от чего отталкиваться.
А, ещё по выбору WinForms, почему именно оно. Хочется получить многоплатформенность нахаляву, и прототип показал, что реализация WinForms в Mono достаточно хорошая, так что он без пересборки запускается и даже работает в Ubuntu и MacOSX (правда, после обновления Mono на Mac оно стало падать при старте где-то в загрузке шрифтов при конструировании формы, но я думаю, это решаемо).
Re: Архитектура Rich Client приложения на .Net. Как?
Здравствуйте, Mishka, Вы писали:
M>1. Что у нас есть сейчас? M>2. Что мы хотим получить на выходе? M>3. Сколько это будет стоить? M>4. Сколько мы на этом заработаем?
M>4-3 < 0 — не фиг ничего менять.
M>Лучше на пункт 2 обрати побольше внимания. Технологий много, но это не значит, что их надо использовать.
Спасибо за ответ! По пунктам примерно так:
1. Сейчас есть прототип приложения с не полностью реализованным функционалом. Известно, что функционал будет наращиваться. Реализация сейчас достаточно прямолинейная и уже сейчас видно, что развитие в том же ключе превратится в ад.
2. На выходе хочется получить упорядоченную структуру приложения с тем чтобы его развитие было относительно простым занятием без головной боли при необходимости добавить новый тип данных или, грубо говоря, пункт меню.
3. Это будет стоить моё рабочее время, затраченное на разработку
4. Сколько точно заработаем, сказать затруднительно, т.к. это приложение для внутреннего использования. Оно сократит ручной труд на других проектах и ускорит их выпуск.
Это не какое-то большое многозвенное корпоративное приложение, это скорее однопользовательская утилита, похожая на Visual Studio, только с меньшим функционалом. Мне не нужно много, достаточно только грубой прикидки, что где должно быть и как друг с другом взаимодействовать. Например, нужен ли глобальный менеджер событий, в таком роде. Сейчас разные объекты просто подписываются на события друг друга, и видно, что это увеличивает сложность.
Re[3]: Архитектура Rich Client приложения на .Net. Как?
Здравствуйте, MNZ, Вы писали:
MNZ>Это не какое-то большое многозвенное корпоративное приложение, это скорее однопользовательская утилита, похожая на Visual Studio, только с меньшим функционалом. Мне не нужно много, достаточно только грубой прикидки, что где должно быть и как друг с другом взаимодействовать. Например, нужен ли глобальный менеджер событий, в таком роде. Сейчас разные объекты просто подписываются на события друг друга, и видно, что это увеличивает сложность.
Я понимаю, какой ответ ты ищешь, но в данном случае не существует "правильного" решения. Я могу посоветовать писать это всё на Java, взяв это с потолка, и могу даже аргументировать свой выбор. Проблема не в том, что я не знаю всех деталей, а в том, что на эти детали ты не обращаешь внимания:
1. Что у нас есть сейчас? — что сейчас делают пользователи с теми задачами, которые ты хочешь решить? Нормальные приложения не растут на пустом месте, должна существовать необходимость в них.
2. Что мы хотим получить на выходе? — ты знаешь что пользователи делают сейчас. Предположим они получат твоё приложение, как это повлияет на их работу? Что изменится? На выходе мы не получаем приложение, мы получаем изменённые бизнес процессы.
3. Сколько это будет стоить? — если ты работаешь на кого-то, то есть стоимость твоего времени. Цена содержания одного разработчика в Лондоне, например, в районе 200К, это включает в себя твою зарпалту, место в офисе, электричество и пр. и пр. Рекомендую узнать сколько ты стоишь и посчитать цену проекта умножив на число дней, которое ты потратишь. Далее, в зависимости от технологии возможны дополнительные расходы. VS — не бесплатна, используя её в разработке, ты платишь за лицензии и заставляешь компанию в будущем быть привязаным к ней. Если будешь использовать что-то вроде DevExpress — опять же лицензии, поддержка и пр. Сколько будет стоить установка твоего приложения? Это не бесплатное удовольствие, либо ты, либо кто-то из саппорта будет тратить время на установку. Поддержка, включая обучение, сколько времени будет потрачено в течении года и кто это будет делать?
4. Сколько мы на этом заработаем? — зная, как изменится процесс для пользователя, можно постараться понять сколько денег твоё приложение добавляет в общий процесс. Это не легко, но есть способы приблизительной оценки.
Есть разница между "что" ты хочешь сделать и "как" ты это будешь делать. Я рекомендую для начала определиться с "что". "Как" ты это будешь делать — это обычно вторичный вопрос, и хотя большинство программистов предпочитают именно с него начинать, я бы порекомендовал заставить себя отрешиться от технических вопросов и сконцентрироваться на вопросах бизнеса. Не удивлюсь, если определив "что" ты увидишь, что "как" может быть практически чем угодно, и именно поэтому не существует однозначного "правильного" решения для твоей проблемы. Когда необходимость бизнеса удовлетворена детали реализации оставляются на твоё персональное усмотрение.
Re[4]: Архитектура Rich Client приложения на .Net. Как?
Здравствуйте, Mishka, Вы писали:
M>Есть разница между "что" ты хочешь сделать и "как" ты это будешь делать. Я рекомендую для начала определиться с "что". "Как" ты это будешь делать — это обычно вторичный вопрос, и хотя большинство программистов предпочитают именно с него начинать, я бы порекомендовал заставить себя отрешиться от технических вопросов и сконцентрироваться на вопросах бизнеса. Не удивлюсь, если определив "что" ты увидишь, что "как" может быть практически чем угодно, и именно поэтому не существует однозначного "правильного" решения для твоей проблемы. Когда необходимость бизнеса удовлетворена детали реализации оставляются на твоё персональное усмотрение.
Мы, наверное, смотрим на вопрос с разных уровней абстракции. Конечно, всё упомянутое имеет место, но в данный момент оно меня не касается напрямую, и это в общем даже хорошо. Я программист, у которого возник конкретный технический вопрос, ответ на который я пытаюсь найти. Что-нибудь вроде такого, только более приближенное к реальности. И я было подумал, что подобные задачи по проектированию решались настолько часто, что стали типичными, и опытному человеку сразу придёт на ум какое-нибудь устоявшееся решение.
Re[5]: Архитектура Rich Client приложения на .Net. Как?
Здравствуйте, MNZ, Вы писали:
MNZ>Здравствуйте, Mishka, Вы писали:
M>>Есть разница между "что" ты хочешь сделать и "как" ты это будешь делать. Я рекомендую для начала определиться с "что". "Как" ты это будешь делать — это обычно вторичный вопрос, и хотя большинство программистов предпочитают именно с него начинать, я бы порекомендовал заставить себя отрешиться от технических вопросов и сконцентрироваться на вопросах бизнеса. Не удивлюсь, если определив "что" ты увидишь, что "как" может быть практически чем угодно, и именно поэтому не существует однозначного "правильного" решения для твоей проблемы. Когда необходимость бизнеса удовлетворена детали реализации оставляются на твоё персональное усмотрение.
MNZ>Мы, наверное, смотрим на вопрос с разных уровней абстракции. Конечно, всё упомянутое имеет место, но в данный момент оно меня не касается напрямую, и это в общем даже хорошо. Я программист, у которого возник конкретный технический вопрос, ответ на который я пытаюсь найти. Что-нибудь вроде такого, только более приближенное к реальности. И я было подумал, что подобные задачи по проектированию решались настолько часто, что стали типичными, и опытному человеку сразу придёт на ум какое-нибудь устоявшееся решение.
Казалось бы задача типична, но решений уйма. Я бы сделал следующее: описал бы модель данных, те же классы на С#. Поскольку я не большой любитель ОО, то потом создал бы классы-сервисы, которые с данными будут работать. Тут можно использовать всеми любимую dependency injection, хорошо для TDD, общего развития и кармы. Далее вопрос взаимодействия сервисов, я предпочитаю события вместо прямых вызовов, то есть будут нужены классы, занимающиеся хореографией всего этого дела по модели "событие-вызов сервиса-генерация событий". Всё это естественно с поддержкой многозадачности. В этот момент UI всё ещё нет (есть Model и Controller, нет View), но есть тест классы, генерирующие события. Далее смотрим на UI. Я бы взял DevExpress поскольку красиво и быстро и присобачил всё это дело к классам хореографии. Итого, модульно, расширяемо, тестируемо.
Re[6]: Архитектура Rich Client приложения на .Net. Как?
Здравствуйте, Mishka, Вы писали:
M>Казалось бы задача типична, но решений уйма. Я бы сделал следующее: описал бы модель данных, те же классы на С#. Поскольку я не большой любитель ОО, то потом создал бы классы-сервисы, которые с данными будут работать. Тут можно использовать всеми любимую dependency injection, хорошо для TDD, общего развития и кармы. Далее вопрос взаимодействия сервисов, я предпочитаю события вместо прямых вызовов, то есть будут нужены классы, занимающиеся хореографией всего этого дела по модели "событие-вызов сервиса-генерация событий". Всё это естественно с поддержкой многозадачности. В этот момент UI всё ещё нет (есть Model и Controller, нет View), но есть тест классы, генерирующие события. Далее смотрим на UI. Я бы взял DevExpress поскольку красиво и быстро и присобачил всё это дело к классам хореографии. Итого, модульно, расширяемо, тестируемо.
На случай, если в будущем кто-нибудь ещё будет озадачиваться таким же вопросом, из наиболее близкого к теме мне удалось найти следующее:
Здравствуйте, MNZ, Вы писали:
MNZ>Имеется прототип desktop приложения на WinForms, который пришло время начать делать хорошо.
Собственно тут как и везде надо прочитать много про семейство всяких MVC. Была куча разных UI и везде использовался типа MVC но везде он был сделан по своему.
Если вам нужна кроссплатформенность, то я бы наверное взял Java, хоть я с ней никогда особо не работал. Но mono по документам на линухе вообще нет.
По поводу IShell, ICommand и так далее, надо дизайнить от задачи.
Re[2]: Архитектура Rich Client приложения на .Net. Как?
Здравствуйте, diez_p, Вы писали:
_>Здравствуйте, MNZ, Вы писали:
MNZ>>Имеется прототип desktop приложения на WinForms, который пришло время начать делать хорошо.
_>Собственно тут как и везде надо прочитать много про семейство всяких MVC. Была куча разных UI и везде использовался типа MVC но везде он был сделан по своему.
Вот сейчас как раз активно занимаюсь чтением
_>Если вам нужна кроссплатформенность, то я бы наверное взял Java, хоть я с ней никогда особо не работал. Но mono по документам на линухе вообще нет.
Нет уж, на Java я точно ничего не буду делать, т.к. знаком с ней только на уровне Андроида. Поставить что-то дополнительно хоть на Линукс, хоть на Мак — вообще не проблема, потому что, как я говорил выше, эта штука будет исключительно для внутреннего использования. Сейчас у нас вот так же кроссплатформенно используется набор консольных утилит, написанных на C#, и такой подход мне очень понравился, поэтому вопрос выбора, .NET или не .NET, даже не стоял. А на Убунту так вообще такие приложения автоопределяются, так что даже mono в командной строке приписывать не надо.
Re: Архитектура Rich Client приложения на .Net. Как?
Да тут в принципе вопрос так стоит: Цепляться из презентативного слоя прямо к файлам или использовать промежуточную абстракцию как модель и адаптер над файлами.
Судя по тому, что планируется некоторые файлы обрабатывать как единое целое, я думаю следует выбрать второй вариант.
, т.к. хочется изначально избежать хотя бы детских ошибок, если всё-таки придётся делать архитектуру самому. Про такие технологии, как DI и IoC слышал, но не более того, также слышал про Prism, Autofuc и Caliburn.Micro, но тоже не более того. В идеале, мне нужно примерно следующее, желательно без лишних сложностей:
