Comments 16
Несколько занятных вопросов.
- Какую именно логику вы повторно используете между разными хостами (особенно — между Windows Forms и asp.net)?
- Как вы реализуете эффективную работу с IO (все обращения к удаленным сервисам) без
Taskиasync? - Почему вы не взяли готовую систему плагинов (начиная с MEF)?
Какую именно логику вы повторно используете между разными хостами (особенно — между Windows Forms и asp.net)?
DAL во всех случаях переносится на «ура». В теории можно переносить и BLL, если в логике нет взаимодействия напрямую с пользователем.
Для примера, в приложении TTManager, который вскользь упомянут в статье, в ядре BLL, Windows.Forms используется в двух случаях:
1) Для аутентификации, с аргументом Boolean silent (Т.е. либо вылетит с исключением, либо сначала покажет WinForms окно с вводом логина и пароля).
2) Для выбора DAL плагина, если их найдено более одного. Соответственно, в ASP.NET окружении, при задвоении DAL плагинов, приложение вылетит с ConfigurationException.
Сейчас в процессе хост на OWIN, который позволит отдавать методы помеченные как public, в виде REST методов. Для примера:
//server.com/MyApplication/Plugins — Список всех подгруженных модулей и публичные методы в удалённом хосте
//server.com/MyApplication/Plugin/{PluginId}/{MethodName}/ [POST: payload] — SET методы, GET: [queryString payload] — GET методы.
Увы, пока меня ещё не всё устраивает в текущей версии OWIN хоста, поэтому и не выпустил…
Как вы реализуете эффективную работу с IO (все обращения к удаленным сервисам) без Task и async?
Я-бы себя не назвал экспертом в асинхронных приложениях, поэтому вопрос эффективности достаточно спорный. Но если используемая версия фреймворка не позволяет использовать async, то я обходился ThreadPool либо TPL.
Почему вы не взяли готовую систему плагинов (начиная с MEF)?
MEF и MAF — действительно классные фреймворки, но я хотел сделать базовый слой, который содержит минимум кода и, соответственно, требует минимального фреймворка, дабы была возможность запускать приложение на WinXP или WinMobile 6.5. Ну и поменять рантайм в [web/app].config'е с v2.0 на v4.0 куда проще чем в обратную сторону.
Сейчас в процессе хост на OWIN, который позволит отдавать методы помеченные как public, в виде REST методов.
То есть то, что логика REST-сервисов и UI-приложений различается, вас не смущает?
Но если используемая версия фреймворка не позволяет использовать async, то я обходился ThreadPool либо TPL.
Для TPL нужен .net 4+. У вас в ядре — 2.0.
дабы была возможность запускать приложение на WinXP или WinMobile 6.5.
На дворе, вроде бы, 2016 год. Вам точно это нужно?
То есть то, что логика REST-сервисов и UI-приложений различается, вас не смущает?
Увы, грамотного решения, которое позволит отбразить UI одновременно в ASP.NET и WinForms приложении я не нашёл. Давным давно, видел одно решение, которое пыталось отрендерить WinForms приложение через Silverlight, но о дальнейшем развитии приложения я не слышал.
Про REST методы я говорю в контексте использования клиентских фреймворков, таких как ExtJS.
Для TPL нужен .net 4+. У вас в ядре — 2.0.
Да, ядро скомпилировано на 2.0, но при добавлении в конфиг рантайма 4.0, мы можем использовать в коде компоненты фреймворком выше. Т.е. указав в конфиге рантайм 4.0, я могу использовать плагины, которые используют TPL, MemoryCache, ClaimsIdentity и пр…
При использовании рантайма 2.0 этот модуль просто не запустится и в логе будет сообщение:
BadImageFormatException:
This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded. (Exception from HRESULT: 0x8013101B)
На дворе, вроде бы, 2016 год. Вам точно это нужно?
Поддержка POSReady 2009 (Практически WinXP но с некоторыми свистелками) заканчивается в 2019 года.
Casio IT-600 на складах ещё используется. Я пару лет назад писал про это устройство один коммент. Тут на хабре:
https://habrahabr.ru/post/235869/#comment_7953111
Но это вовсе не значит, что не стоило ее реализовывать еще раз
Тогда до кучи стоило помянуть Zonnon — являющийся кстати .NET языком и, самое главное, задать куда более интересный вопрос — а что с тех пор изменилось — что в этой реализации было сделано лучше предшествующих? Что ещё нужно будет сделать, чтобы уйти ещё дальше в сторону совершенства?
Что в этой реализации было сделано лучше предшествующих?
Я преследовал несколько целей:
- Не завязывать модуль на конкретный хост. Иначе это превратится в очередной BizTalk.
- Лёгкое изымание сборки из модульной архитектуры и встраивание в приложение через reference.
Не устроила Вас работа сборки в плагинной архитектуре, добавили её в проект через reference и продолжаете использовать публичные классы и интерфейсы.
Либо наоборот, добавили класс наследуемый от IPlugin и встроили в модульную инфраструктуру
Что ещё нужно будет сделать, чтобы уйти ещё дальше в сторону совершенства?
Вот прямо сейчас, мне очень не хватает ClaimsIdentity провайдеров для распространённых у нас социалок. По работе сейчас внедряю отдельный SSO сервер на основе OpenId Connect, и приходится вручную переносить весь «завод» провайдеров из старой OAuth аутентификации в IAppBuilder… Эта ручная работа немного угнетает…
И было-бы неплохо реализовать ServiceBus, который мог-бы работать как с RabbitMQ, так и с MSMQ. Сейчас в ентерпрайзе крутится код с MSMQ, но он ещё недостаточно поработал, чтобы его можно было-бы оформить отдельным модулем.
По поводу OWIN и REST диалога между одним хостом и другим, то это чисто познавательная работа, ибо есть идея, сделать из одного приложения толстого клиента. Т.е. либо оно работает полностью локально через локальный провайдер плагинов, либо оно становится толстым клиентом и грузит данные из облака через REST провайдер плагинов. А в облаках крутится хост, который грузит локально те плагины, которые раньше были локально.
Что из этого выйдет — пока сам не знаю…
Можно вложить в архитектуру следующий принцип — для принятия обоснованного решения разработчик, должен прочитать как можно меньше кода (тогда ваши наработки будут ценны в бизнесе, где, как известно время-деньги (которые д. б. ещё вчера)), модульная архитектура очень этому поспособствует (см. https://habrahabr.ru/post/311014/#first_unread
а про идеи, которые стоит воплотить в виде состояния "из_коробки" в тестовой оснастке для архитектуры стоит посмотреть:
тут описаны проблемы
https://habrahabr.ru/company/jugru/blog/309502/#first_unread
здесь-показана автоматизация тестирования как пример решения (неидеального)
https://habrahabr.ru/company/acronis/blog/282682/#first_unread) — про бизнес-ценность этого — написал выше.
https://habrahabr.ru/post/303032/?reply_to=9842418#comment_9841066
А вот про это:
https://habrahabr.ru/post/311014/#first_unread
За всё то время, сколько я проработал в проектах на .NET'е, я обратил внимание на 2 проблемы, которые способствуют замусориванию кода:
1) Нежелание чистить код или пересматривать весь кусок, если того требует итерация.
2) Оставить или написать заранее код по принципу «А вдруг пригодится».
Причём как с первой проблемой я сталкивался не очень часто. А вот со второй проблемой, увы, наталкиваюсь чуть-ли не постоянно… Причём такие косяки встречаются даже у авторов учебников по программированию… (Первый раз натолкнулся в книге Дино Эспозито про первую версию MVC).
Так что я думаю, что многие вредные абстракции как раз выливаются из выражения «А вдруг пригодится».
1) Нежелание чистить код или пересматривать весь кусок, если того требует итерация.
2) Оставить или написать заранее код по принципу «А вдруг пригодится».
1) Нежелание чистить код или пересматривать весь кусок, если того требует итерация.
2) Оставить или написать заранее код по принципу «А вдруг пригодится».
Страх человека:
А) перед лишними усилиями;
Б) перед ошибками (удалил действительно пригодившуюся впоследствии функциональность),
заставляет так его вести себя. Избавьте его от страхов с помощью модульности, системы версий и жить станет проще — сейчас, например пункт Б уже не столь актуален, если есть версии.
Кстати — большинство современных языков появились из исследовательских прототипов, решающих частные задачи конкретного исследователя — просто программисты гиенами накинулись на новинку и потащили её в промразработку, не думая о последствиях. Только некоторые из языков проектировались с явным и чётким намерением использовать их в промразработке: скажем, — Сobol, Ada, Java, C#, в телекоме — Erlang. Например, если о безопасности языка начали помаленьку думать на стадии его проектирования то, мало кого из академических разработчиков языков интересует проблема производительности обычного офисного программиста.
Ещё раз кстати, раз архитектура применяется на таком месте как склады, то можно изначально добавить в неё новую, важную для бизнеса возможность — возможность крутиться на сколь угодно старой технике и без проблем переходить на новую — бизнесу важно отбить затраты, поэтому можно ожидать, что в следующие 50-60 лет учёт на складах (и не только — везде почти так будет — так в своё время было с радиотехникой и телефоном: сначала это были военные разработки или высокие технологии — а потом радиоаппаратура и телефоны в каждой квартире и на каждом рабочем месте) будут вести на технике, пока она не сдохнет с коротким замыканием (https://habrahabr.ru/company/ibm/blog/177683/) — с приходом "интернета вещей" бизнес породит спрос на дешевые, долговечные, нетребовательные промкомпьютеры. Но такой подход потребует специализированного, ориентированного на долговечность и "железонезависимость" проектирования встроенных контейнеров и виртуальных машин, "абстрактных машин языка программирования", мощной ориентированности на облака и сети, ориентированности на производительность программистов.
Всё это тоже можно попробовать прикрутить к Вашему комбайну.
поэтому можно ожидать, что в следующие 50-60 лет учёт на складах (и не только — везде почти так будет — так в своё время было с радиотехникой и телефоном
Сейчас получается картина с железом, аналогична разрешениями на машинах пользователей. Топ 5 разрешений по популярности на одном из пректов (Из 20млн. за месяц):
1. 1366x768 (21,09%)
2. 1920x1080 (17,59%)
3. 1280x1024 (13,29%)
4. 360x640 (7,41%)
5. 1600x900 (6,63%)
…
Аналогичная тенденция с железом, либо старенький системник на NT, либо монтажные сервера Nв1 с виртуализацией и прочими свистелками…
Всё это тоже можно попробовать прикрутить к Вашему комбайну.
Я как раз это и хочу реализовать, чтобы логика и слой доступа к данным, не зависели от хоста. Т.е. чтобы всё одновременно могло крутиться в одном процессе, а при возрастании нагрузки, без затрачивания ресурсов, выноситься в отдельные процессы/сервера.
По сути, мне-бы надо всё это реализовать на .NET Core, это как раз тот самый форк .NET'а, который подразумевает минимальную зависимость от FCL. Может, тогда он и получит больше заинтересованных…
Но одного меня на это не хватит, ибо я этим занимаюсь в свободное время, раскапывая готовый код. Как думаете, будет-ли больше заинтересованных, если я реализую всё это в open source?
Будет, если Вам удасться залучить в этот опенсурсный проект вечно занятых, держащихся за болящую от проблем голову программистов-практиков. А вот как это сделать — над этим нужно очень, очень хорошо подумать.
Например, можно сделать это, избавив их от толики головной боли — грубо говоря, у них есть проект, старый проект и нужно что то с ним делать, возможно — переписывать. Но вместо переписывания можно пересадить его на Вашу платформу по принципу "тыркнул-пыркнул: завелось" и тогда он проработать может ещё десятилетие или более.
По хорошему стоит продумать основы платформы исходя из того, что любые резкие телодвижения на ней недопустимы, раз она предназначена для "консервации" проектов, для предотвращения их загнивания. Разработка таких концептуальных основ тоже занятие требующее весьма усиленных размышлений, мне пока только ясно, что платформа должна являться как бы отражением основных концепций .NET — так как это то, что будет объединять самые разнородные проекты.
https://ru.wikipedia.org/wiki/OSGi
Никому не нужны такие комбайны — в том числе и вам. Это неэффективно, негибко и очень сложно в поддержке, особенно, если какой-то функционал захочет большего и в угоду ему придется перетягивать одеяло.
Тем более сидеть на .NET 2.0 это вообще не комментируемо даже.
Ладно бы интересно было разрабатывать, но писать все на инструменте 10-летней давности — это за гранью.
Может проще на ваших складах поменять аппаратную часть? Или хотите положить вашу жизнь на разработку системы, от которой можно отказаться щелчком пальца и тупо поменяв аппаратную часть и софт?
Иногда смотришь и не можешь понять, зачем люди делают некоторые вещи, а потом понимаешь — просто переклинило человека и он сидит на своей волне и воообще не понимает потребностей текущих реалий.
Я ждал этого комментария :)
Никому не нужны такие комбайны — в том числе и вам
От чего-же комбайны? Наоборот, код получается очень лёгким. При этом, если готовое решение Вам не подходит, Вы можете написать своё и не использовать готовые. Смысл в том, что хост может быть универсальным, таким как MDI,SDI и пр… А может быть узкоспециализированным и заточенным под конкретну задачу. Для примера: http://www.zetuniverse.com/
При этом, использовать уже написанные модули.
Если взять с архитектурной области, то вот Вам несколько практик из жизни:
1) RabbitMQ на ферме с большим количеством виндовых сервисов
2) Масштабирование приложения на ферму и перенос кеша с MemoryCache на кеширующие сервера
3) Слоёное накладывание тестов, начиная от отдельного компонента, заканчивая решением целиком
Это неэффективно, негибко и очень сложно в поддержке
А почему сложно поддерживать?
особенно если какой-то функционал захочет большего и в угоду ему придется перетягивать одеяло
Это зависит от того, насколько правильно Вы выстроили архитектуру. В противном случае, если архитектура в приложении выстроена неправильно, то проще всё приложение выкинуть на помойку…
Нам сейчас досталось одно MVC приложение на поддержку от аутсорсеров, где PM подразумевал итеративное развитие проекта, а разработчики решили выстроить водопадое развитие… Да, с одной стороны всё написано грамотно, разделено на слои (а затем ещё на слои, и ещё на слои...) с использованием Entity FW в качестве ORM.
Но как только от бизнеса пришло условие переписать всё на базу с использованием фиксированных методов, то 70% кода пришлось просто выбросить и оставить только вьюхи. Хотя я не сторонник переписывать всё что пришло от других комманд, уже наступал на эти грабли…
Тем более сидеть на .NET 2.0 это вообще не комментируемо даже
CLR v2.0 — это минимум для интерфейсов.
У Вас есть преложения, как улучшить интерфейсы с использованием CLR > v2.0?
Влияет-ли это на производительность? Давйте проверим:
Напишем простое WinForms приложение на, скажем, .NET 3.5 и запустим его под CLR v2.0. При запросе:
System.AppDomain.CurrentDomain.GetAssemblies() увидим следующую картину:
mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
SampleApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Xml, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Windows.Forms, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Drawing, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Затем, откроем SampleApp.config и добавим следующий код сразу после </configSections>:
<startup>
<supportedRuntime version="v4.0" />
<supportedRuntime version="v2.0.50727" />
</startup>
Опять запускаем наше приложение:
mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
SampleApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
Т.е. благодаря AssemblyRedirect, мы запустились в окружении CLR 4.0.
Соответственно, дальнейшее использование компонентов ограничено только возможностями последнего .NET Framework'а.
Или хотите положить вашу жизнь на разработку системы, от которой можно отказаться щелчком пальца и тупо поменяв аппаратную часть и софт?
Увы, аппаратная часть на всех складах на территории бывшего СНГ «щелчком пальца» не меняется. Поэтому при переходе на более новую аппаратную часть, отпадает только часть визуальных компонентов, которые заточены под конкретное устройство.
Модульная архитектура и многоразовый код