Ад дотнета

[metaclass]

Тут недавно выпустили akka.net, которая, по идее, сможет решить большую часть проблем с асинхронным обменом сообщениями для моего софта.
Сижу читаю всякое по теме, набрел на такую ссылку: http://www.aaronstannard.com/the-profound-weakness-of-the-net-oss-ecosystem/ - это один из разработчиков akka.net, занимавшийся ее remoting-кишками.

Вкратце: "если на дотнете делать что-то сложное и осмысленное - садись и пиши фреймворки с нуля, потому что индусам и микрософту ничего этого не надо".

Еще одна забавная хрень оттуда же: они подумали и вместо переезда своего приложения с дотнета на jvm, решили спортировать акку с jvm на дотнет. Это только с первого взгляда выглядит странным в рамках религии "мы не занимаемся изготовлением инструментов", но если сравнить приложение со сложной бизнес-логикой, разрабатываемое 2-3-5 лет и фреймворки - может оказаться, что портировать вторые потребует гораздо меньше времени.

Comments

[jakobz.livejournal.com]

Ну, в серверном дотнете даже не с акторов начинается. Там же негде хостить серверные приложения по-человечески.

Есть типа IIS, который сложно заставить просто не выключаться. Т.е. какие-нибудь фоновые процессы там нельзя хостить. Не говоря уже о том, .NET туда воткнут откровенными хаками.

Есть windows services, которые надо руками каждый раз прикручивать, придумывать как их деплоить, как мониторить.

Т.е., грубо говоря, в дотнете нет Application Server-а. Какие там в жопу асинхронные агенты?

[anonim-legion.livejournal.com]

>Есть типа IIS, который сложно заставить просто не выключаться

Можете подробнее?

capcha: no-brainer

[metaclass.livejournal.com]

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

А вещи вроде "раз в 10 минут выполнять какую-нибудь обработку" в таком варианте вообще поместить некуда.

[enternet.livejournal.com]

Сгущает он без меры. Необходимость Application Server вообще надумана. Длинные процессы всё равно живут на других машинах, на вебсервере им не место. Но если очень хочется, есть параметры, их можно подкрутить и IIS не будет засыпать.

[metaclass.livejournal.com]

А почему бы все в одном процессе не держать? Тем более, что "другие машины" - это уже какой-то энтерпрайз на тыщи человек, на 10-100 хватает одного сервера.

[binf.livejournal.com]

не, ну так для маленьких надо делать self-hosted. OWIN например, очень гут

[enternet.livejournal.com]

Да ради бога. Только не надо этой фиксации на IIS. Можно уже закопать стюардессу. Пишите под катану (последний MVC) это и майкрософт рекомендует и будет там один негасимый процесс.

[gemelen]

К этому есть две хорошие цитаты автора по ссылке в посте:
The paramount technical challenge facing the majority of .NET developers today looks like building Web APIs that serve JSON over HTTP, judging from the BUILD 2014 sessions. Distributed computing, consistent hashing, high availability, data visualization, and reactive computing are concepts that a virtually absent from the any conversation around .NET.
...
Compare this to the Java ecosystem: virtually every major .NET project is a port of something originally evented for the JVM. I’m looking at you, NAnt, NUnit, NuGet (Maven), NHibernate, Lucene.NET, Helios, Akka.NET, and so on
:)
PS: капча внезапно доставляет

[binf.livejournal.com]

Для больших приложений - azure, меньше тыщи человек - self hosted