Pull to refresh
Comments 60
Первое, что вы заметите, когда первый раз скомпилируете приложение под NFX, это — как быстро пройдет компиляция.

Хм, приложения «под NFX» чем-то отличаются от приложений под «обычный .net» в части компиляции? Это не .net? Используется другой компилятор?

А можно ли использовать NFX в IoC устройствах?

Что такое «IoC-устройство»?

К сожалению, JSON, по ряду конкретных причин, плохо подходит для конфигурационных файлов.

Каких именно «конкретных причин»?
Сразу оговорюсь, я здесь выступаю в виде пользователя и мало что знаю о потрохах NFX. Насколько понимаю, количество referenced assembly сильно влияет на время компиляции. Здесь у нас 1 шт. Может есть какие-нибудь доп.оптимизации (вопрос к разработчикам. Ау?). Обычно на моем лаптопе приложения, с кот.я работаю, компилируются несколько [ десятков] секунд. А здесь — доли секунд.

Оопс… IoT (Internet of Things) — спасибо за найденную ошибку!!!

C JSON: один пример: нет стандартного метода задавать имя объекта. Т.к. к примеру, class Test. В XML будет: <ns:Test>…, а в JSON: { _name: «Test»… что-то типа этого, т.е.выдумывать нестандартные методы, чем, кстати, многие и занимаются.
Насколько понимаю, количество referenced assembly сильно влияет на время компиляции.

Есть хотя бы одна статья, подтверждающая это предположение?

Здесь у нас 1 шт.

А от System вы не зависите?

Обычно на моем лаптопе приложения, с кот.я работаю, компилируются несколько [ десятков] секунд. А здесь — доли секунд.

Solution, который у меня был по руками (13 проектов, реально собиралось 8, 55 nuget-пакетов зависимостей, не считая системных сборок), собрался за несколько (меньше пяти) секунд (не десятков), причем большую часть этого времени система забирала нехватающие пакеты. Окей, clean solution, build solution — на билд 13 проектов уходит три секунды, причем зависимостй там нигде не меньше пяти, а в фронтендовых — больше двух десятков на проект.

C JSON: один пример: нет стандартного метода задавать имя объекта. Т.к. к примеру, class Test. В XML будет: <ns:Test>…, а в JSON: { _name: «Test»… что-то типа этого, т.е.выдумывать нестандартные методы, чем, кстати, многие и занимаются.

А нет такой вещи, как «имя объекта», поэтому и задать «стандартными способами» его нельзя. Обычно такие вещи прекрасно решаются через key-value pair.
Подумал-подумал. Вы правы. Какая разница 5 сек или 0.5 сек. Пусть даже 30 сек. на компиляцию — это совершенно неважно. Пойду текст поправлю.

«имя объекта», тоже лажанулся. должно быть «имя класса».
Какая разница 5 сек или 0.5 сек. Пусть даже 30 сек. на компиляцию — это совершенно неважно.

Да разница-то есть, только вопрос, есть ли на самом деле этот разброс времени, или нет.

«имя объекта», тоже лажанулся. должно быть «имя класса».

Во-первых, аналогично, и в XML, и в JSON нет такой вещи, как «имя класса», потому что они не предназначены для объектно-ориентированной парадигмы. А во-вторых, и там, и там есть расширение, позволяющее указать тип элемента — в XML это xsi:type, в JSON — $type. Другое дело, что и там, и там без него чаще всего можно обойтись, если продумать семантику документа.
В laconic я могу написать:
Tests {… }
Как я это сделаю в JSON?

По сути я с вами согласен. Давайте будем считать laconic расширением JSON, заточенным под данную задачу.
Как я это сделаю в JSON?

А что вы хотите сделать? Что такое «Tests»? Какое место в модели оно занимает?

Давайте будем считать laconic расширением JSON, заточенным под данную задачу.

Нет, laconic — не расширение JSON, потому что laconic не является валидным JSON.

Собственно, вопрос, по каким же конкретным причинам json не подходит для конфигурационных файлов, остался открытым.
Laconic nikakogo otnoheniya K JSON ne imeet voobshe.

Eto format imenno dlya configa. on podderjivaet takie udobnie veshi kak:
1. bukvalnie stroki a-la C# $" i can span many lines \not escape"
2. uproshennuju grammatiku bez operatorov «my+va-+-+lue=1 2 2», imena kluchei moigyt tozhe byt strokami
3. commenti: sngle line, multi line
4. true hierarchy without root object/array requirements

i chto samoe glavnoe, chto LACONIC voobshe ne trebuetsya.
Vy mojete napisat tot-zhe file s extension XML i vse budet rabotat na XMLe

look, this is NFX config in XML:
github.com/aumcode/nfx/blob/master/Source/Testing/Manual/WinFormsTest/WinFormsTest.configuration
Laconic nikakogo otnoheniya K JSON ne imeet voobshe.

Спасибо, я в курсе. Утверждение «давайте будем считать laconic расширением JSON» принадлежит Leo_Gan.

Меня существенно больше интересует, почему JSON не подходит для задачи, описанной в посте.
yes, and this is extremely inconvenient.
try to convert this to JSON:

node
{
// no-log=true
server=local{ binding=sync{tcp-window=16k} binding=async{ tcp-window=16k}}
welcome=$«Hello {0},
— you have connected to {1}»
}
(Хабр — русскоязычный сайт, по-английски я могу и на SO поговорить)

А что здесь надо сконвертировать в JSON? Какая модель за этим стоит, какая у нее семантика?

(я, заметим, не считаю, что JSON идеально подходит для конфигов, но есть ведь и YAML)
{
  "server": {
    "type": "local",
    "bindings": [
      { "type": "sync", "tcp-window": "16k" },
      { "type": "async", "tcp-window": "16k" }
    ],
    "welcome": "«Hello {0}, \n— you have connected to {1}»"
  }
}


Чего еще не хватает?..
Why «Type»? Why not «name»? or anything else?

so how will this look in JSON?

friend=true
{
  type="Oslik"
  name="Drug Ezhika"
}
вы даже не прочитали внимательно ответ.
в JSON невозможно создать ноуд валуе без имени в принципе.

  node=45{} 


в ХМЛ и прочих иерархических форматах запросто.
ЙСОН это object формат, у него нет корня без аттрибутов
поэтомы я вас попросил написат на JSON- вы же даже не удосужились вникнуть в проблему —
в вашем примере будет введен «type» суррогатныи ноуд. А если ноуд с таким именем уже есть?

вообше поражает что здесь никто не пытается даже прочесть ответ, не говоря о вникании в суть
Вы проблему сначала описали бы, что ли. Я, заметим, вас уже просил об этом.
Нет, это вы решаете несуществующую проблему. Вам почему-то кажется, что существует априори заданная модель, которую надо выразить в конфиге. И отсюда появляется странное требование отображать конфиги на разных языках 1 к 1.

Но так программы не пишутся! Объектная модель, схема, или что-там-еще файла конфигурации всегда составляется с учетом ограничений парсера и формата.

К чему это я? Вернемся к вашему вопросу:
А если ноуд с таким именем уже есть?
Я просто не будут выбирать это имя для других нодов.
mne kajetsya chto sushestvuet model?
konechno ona sushestvuet. mnogie veshi configuriruytsya iz XML kotoriy byl napisan esho v 2002 gody.

a kto vam skazal chto configurazija voobshe imeet kakoe-libo otnoshenie k JSON?

vot primer configurazii v NFX:

   c:\>dosomething.exe "c:\input.file" "d:\output.file" -compress level=100 method=zip -shadow fast -large

      [args ?1="c:\input.file" ?2="c:\output.file"]
        [compress level="100" method="zip"]
        [shadow ?1="fast"]
        [large]
 

eto odin prosto primer.
potom vy mojete prosto tak «prisobachit eto v klass:

    [Config]
    public int CompressionLevel....

..i ne vazhno voobshe dannie prishli iz XML, INI, command args — eto prosto derevo.
Eto kak raz u vas pochemy-to kasha i tight-coupling mezhdu FORMATOM i soderjimim

configuraizja — eto derevo v pamyati.
XML laconic ili yaml — eto voobshe nevazhno.

A mojet ya xochu derjat eto v SQL servere? pochemu net.

s kakogo boku tyt JSON? on voobshe dlya etoi zadachi nikak ne podxodit
configuraizja — eto derevo v pamyati. [..] s kakogo boku tyt JSON? on voobshe dlya etoi zadachi nikak ne podxodit

Ну, это вы зря. Как раз для отображения «дерева в памяти» JSON подходит ничем не хуже предлагаемого вами же SQL.
кстати, а где комментарии в JSON?
конфиг фаил на 300 строчек, из них болше 25% комменты?

example:
    instrumentation 
    {
        name="Instruments" 
        interval-ms="4395"
        //self-instrumented=true
		
	   /*	provider
		{
			name="Telemetry Instrumentation Provider"
			type=$(/gv/types/$instr-nop) 
		}  */
           
        provider 
        { 
            name="Telemetry Instrumentation Provider"
            type=$(/gv/types/$instr-telemetry) 
            use-log="false"
            receiver-node="sync://127.0.0.1:$(/gv/services/$sync-telemetry)"
        }
    }


Комментариев в json, действительно нет. Зато они есть в yaml и hocon (а так же в xml).
neponyatno pochemy vse zaziklilos na JSON.

Skajite, pochemy configurazija ne mojet byt' naprimer v baze ili commandnoi stroke ili v Mongo documentax?

Pochemy configurazija ne mojet «sobiratsya» dynamicheski is raznix fomatov (naprimer v baze polya, v file XML)?

Vy chto ne ponimaete chto configurazija eto prosto ierarxija imenovanix znacheniy.
Da mojno ispolzovat JSON kak ODIN IZ formatov, no on ochen neudoben.

Kstati, kogda menya zakalibal XML, ya reshil ispolzovat JSON i napisal JSONCOnfig za gde-to 15 miunut.
Potom ya osoznal chto eto ochen neudobno, imenno v svazi s otsutstviem kommentariev
da i strukturno v JSONE v prinzipe net noudov chistoi ierarxii kotorie est v XMLe tom je

neponyatno pochemy vse zaziklilos na JSON.

Мне тоже не понятно, зачем вы спрашиваете «а как сделать вот такое в JSON».

Skajite, pochemy configurazija ne mojet byt' naprimer v baze ili commandnoi stroke ili v Mongo documentax?
Pochemy configurazija ne mojet «sobiratsya» dynamicheski is raznix fomatov (naprimer v baze polya, v file XML)?

Может.

Da mojno ispolzovat JSON kak ODIN IZ formatov, no on ochen neudoben.

Для кого как.

da i strukturno v JSONE v prinzipe net noudov chistoi ierarxii kotorie est v XMLe tom je

Простите, чего именно нет в JSON? Можно на примерах?
Я не знаю, что вы в этом примере называете «noudov chistoi ierarxii», так что затрудняюсь как-то аргументированно с вами спорить о том, что есть в JSON, а чего нет.
CTRL+F «Oslik» — tam primer imenno po etomu.

Dopustim u vas est attribut «type». Ktoto sverxy predlagal ego ispolzovat. Vopros: kak vyrazit takoe derevo na JSON:

friend{name=«Ezhik» age=3 type=«CloseFriendConnection»}

ili takoe:
connect
{
site=http://yahoo.com{}
site=http://google.com{name=«Google» type=""}
}
Я еще раз спрашиваю: так все-таки, семантика какая? А то если переводить в лоб, что все же тривиально:

friend{name=«Ezhik» age=3 type=«CloseFriendConnection»}

friend: {name: "Ezhik", age: 3, type: "CloseFriendConnection"}


connect
{
site=http://yahoo.com{}
site=http://google.com{name=«Google» type=""}
}

connect: 
  [
  "http://yahoo.com",
  {"http://google.com": {name: "Google", type: ""}}
  ]
a esli «friend» vstrechaetsya >1 raza podryad?
group
{
   friend{}
   friend{}
}


i teper nado delat array na JSONe, v etom i neudobstvo.
To pole, to array. JSON eto OBJECT NOTATION format. XML i Laconic eto DATA delimitation format

v etom vsya razniza
i teper nado delat array na JSONe, v etom i ne udobstvo.

Не вижу никакого неудобства. Полезно заранее представлять себе множественные отношения в своих данных.

To pole, to array.

Вообще-то, всегда поле.

JSON eto OBJECT NOTATION format. XML i Laconix eto DATA delimitation format

Ничего не знаю про laconix, а XML — это язык разметки. По большому счету, разметки чего угодно. JSON — действительно, объектная нотация, но если мы и конфиг потребляем как объектную структуру, то ничего плохого в этом нет.

Что в очередной раз возвращает нас к вопросу: чем JSON не подходит для решения задачи, описанной в посте?
posmotrite, u vas «yahoo» eto string v arraye, a google eto object s property imenem «google.com»
vas ot etogo ne korobit?

teper napishite eto na XML (zabudem pro laconic, on yavno mazolit glaza)
i srazy vse stanet proshe
<connect>
  <site>http://yahoo.com</site>
  <site name="Google" type="...">http://google.com</site>
</connect>
posmotrite, u vas «yahoo» eto string v arraye, a google eto object s property imenem «google.com»
vas ot etogo ne korobit?

Нет. Я специально так написал, чтобы показать, что JSON прекрасно вариативен, если мы хотим получать компактные нотации. Если вы хотите строгую запись, то вот она:

connect: 
  [
  {"http://yahoo.com": null},
  {"http://google.com": {name: "Google", type: ""}}
  ]
ya ne poimu smisla voobshe etogo voprosa. ya otvetil: JSON eto OBJECT notation format.
Dlya postroeniya ABSTRACTNIX ierarxiy pamyati on neudoben xotya by potomu chto
on trebyet «key»/value" mapping. Derevo v NFX etogo ne trebuet voobshe.
Naprimer vy mojete imet xot 100 noudov s odnim i tem je imenem.
Eto delaetsya legko na XMLe, t.k on format razmetki texta prosto i vse.

Laconicn udobnee XMLa v razy. Seichas u menya realno ostalos tolko neskolko starix prilojeniy
gde ispolzyetsa XML — prosto uje davno.

Esli vam lichno nujen JSON eto vashe pravo, no vy ubedites sami chto isplzovat ego vmesto Laconic formata
v razy neudobnee. Ya proverial + moi partner proveryal. My daje vybrosili JSONconfig iz NFX t.k ne bylo ni odnoi zadachi.

ya ne poimu smisla voobshe etogo voprosa. ya otvetil: JSON eto OBJECT notation format.

Как это мешает его применению для задач в посте?

Dlya postroeniya ABSTRACTNIX ierarxiy pamyati on neudoben

У нас не абстрактная иерархия, у нас вполне конкретная задача…

Naprimer vy mojete imet xot 100 noudov s odnim i tem je imenem.

… в рамках которой это ваше требование избыточно. Откроем и посмотрим:

tests
       {
           test
           {
           ...
           }
           test
           {
            ...
           }
       }

serializers
      {
           serializer
           {
           ...
           }        
           serializer
           {
           ...
           }        
      }


Это же два тривиальных массива: tests и serializers, и их можно так и записать, не потеряв ни грама семантики.

Esli vam lichno nujen JSON eto vashe pravo, no vy ubedites sami chto isplzovat ego vmesto Laconic formata v razy neudobnee.

Где можно взять пакет для чтения laconic, чтобы я мог в этом убедиться?
Vy mne predlagaete pisat' config v kajdom projekte svoi s nylya?
Ya je vam obyasnil chto NFX.Environment.Configuration eto ne parsanie filov a zeliy
framework, kotoriy imeet okolo 10+ features: macros, variables, recursion, injection etc…

Smotrim tyt:
blog.aumcode.com/2013/08/aum-configuration-as-facilitated-by-nfx.html

Где можно взять пакет для чтения laconic, чтобы я мог в этом убедиться?

Laconic mojno chitat xot na urovne Lexera xot parsera no zachem?
vam nujno Configuration a ne Laconic. Laconinc, command args ili XML eto ne vajno — on sam vse poimet.

smotrite v kod na primere:
driver program: github.com/aumcode/nfx/blob/master/Source/Tools/gluec/Program.cs
conf applied to class: github.com/aumcode/nfx/blob/master/Source/NFX/Glue/Tools/GluecCompiler.cs

Naskolko ya ponyal Leo_gan vzyal primer is proekta SERBENCH
kotoriy tyt:
github.com/aumcode/serbench

vse eti configi mojno napisat na XMLe, configurazija vstroena v NFX Application
koei i yavlaetsya SERBENCH.

posmotrite v kod:
github.com/aumcode/serbench/blob/master/Source/sb/sb.laconf
etot je file mojete peredelat v XML i prosto pomenyaite extension. syt taje, koda net

Vy mne predlagaete pisat' config v kajdom projekte svoi s nylya?

Нет, я предлагаю четко отдавать себе отчет, какую пользу для конкретного решения привносит каждый из его компонентов. Вот Leo_Gan в своем посте явно не может различить, что в архитектуру привносит configuration-driven development, что — laconic, а что — nfx.

zeliy framework, kotoriy imeet okolo 10+ features: macros, variables, recursion, injection etc…

И что из этого понадобилось в решаемой задаче?

Зато этот фреймворк до сих пор не научился — или не научился конкретный программист, им пользующийся — выдавать полностью типизированные аксессоры, чтобы вместо foreach(var tnode in node[CONFIG_TESTS_SECTION].Children.Where(cn => cn.IsSameName(CONFIG_TEST_SECTION))) (серьезно? строковые константы? два уровня вложенности для простого массива?) можно было писать foreach(var tnode in node.Tests).

Laconic mojno chitat xot na urovne Lexera xot parsera no zachem?

Чтобы сравнить, насколько легко работать с ним по сравнению с JSON и YAML.

vam nujno Configuration a ne Laconic. Laconinc, command args ili XML eto ne vajno — on sam vse poimet.

Окей, где можно взять вашу конфигурацию в виде пакета?
ya ponimaju o chem vy govorite. K sojaleniju «zaxvat» features kotoriy obespechivaet NFX
ne ocheviden v scope takix statei kak zdes, poka s etim frameworkom ne porabotaesh na neskolkix raznix zadachax
budet ne vse ponyatno. Vy mojete skazat chto eto ploxo. Pust tak. Real'no mnogie veshi
vyglyadyat ne tak kak dictuet mainstream. Typizazii configa sdelanav NFX no ne tak kak vami ojidaetsya.
Delo v tom chto config eto kak raz prekrasnoe mesto (takje kak DataAccess) dlya dynamic-like languages.
To chto tam napisan kod po injekzii dependencies — eto sdelano spezialno, no sut ne v etom (eto voobshe tema drugogo posta).

tolko-configuraziju otdelno vzyat' nelzya. ya mnogo raz govoril pochemy.

mojno NFX zelikom t.k on UNISTACK.

pm>install-package NFX

ya ponimaju o chem vy govorite

«вообше поражает что здесь никто не пытается даже прочесть ответ, не говоря о вникании в суть „

K sojaleniju «zaxvat» features kotoriy obespechivaet NFX ne ocheviden v scope takix statei kak zdes

Вот именно поэтому я и говорю, что преимуществ в контексте статьи либо нет, либо они не показаны.

Typizazii configa sdelanav NFX no ne tak kak vami ojidaetsya. Delo v tom chto config eto kak raz prekrasnoe mesto (takje kak DataAccess) dlya dynamic-like languages.

Не, не убедили. Как раз динамические (и псевдодинамические) языки бы тем более позволили написать node.Tests вместо node[CONFIG_TESTS_SECTION].Children.Where(cn => cn.IsSameName(CONFIG_TEST_SECTION)).

To chto tam napisan kod po injekzii dependencies — eto sdelano spezialno, no sut ne v etom

В приведенном мной коде нет DI.

mojno NFX zelikom t.k on UNISTACK.

Нет, спасибо, не интересно, у меня уже есть фреймворк, женить два в одном проекте я не собираюсь.
Всё то же самое, но в более краткой записи и меньшим числом кода можно было сделать средствами JSON.NET. Ибо он умеет как грузить объекты по FQN, так и конвертить json-овские объекты в Dictionary<string, T>.
what about macros? recursion detection? pluggable env vars rsolvers? reading constants right from code? structural merging of documents with override rules? tree comparisons, loading config files from any FileSystem (i.e. Git, SVN, Amazon, web etc..)? Is this what you are talking about?

Я в примерах выше перечисленного не вижу. И да, посмотрите в сторону такой штуки как HOCON. Скалисты очень активно используют, им нравится.
youtu.be/reDvhz4RGhA
It takes 60 minutes to describe the features of config WITHOUT going to details.
How come config in .NET has 100+ data types yet it can not do SIMPLEST things like including a file from the web.
If you have ever written anything yourself you know better what kind of pain it is to work with MS configuration.

The lack of variables — the most rudimentary required thing, makes developers to put «mypath='c:\mydata\myfile'» 25 times in the same config.
Ну так не надо пользоваться System.Configuration. Она страшная и древняя. И таки посмотрите на HOCON. Реализацию на шарпе можно раздобыть в составе Akka.NET.
i saw that. it still does not do (at least I did not find) many things that I need as of 2013 i.e.

how can I include a file hosted on a DropBox account as one of my conf sub-nodes?
how can i get a constant value from code in my config?
how do i structurally merge sub-trees with injectable comparison functors?

NFX conf existed back in 2003...sorry

NFX conf existed back in 2003...

И уже умело все описанное вами? Спустя год после выхода первого .net? За пять лет до появления дропбокса?
how can I include a file hosted on a DropBox account as one of my conf sub-nodes?
NFX conf existed back in 2003...sorry
Первый релиз дропбокса состоялся в 2008-ом году. Вам в 2003-ем таки удалось нормально собрать libastral, не иначе. А вообще HOCON умеет грузить куски конфигов из интернета. По остальным двум вопросам ничего не могу сказать, т. к. не возникала ни разу необходимость в подобном. По мержу можно подробнее посмотреть тут.
This is irrelevant. In NFX we havd a concept of a FileSystem, back then I supported WEB and local.
Right now I know a guy uses DropBox.

An ability to include external files via an injectable file0system provider is a really awesome feature.
We use it in cluster, where config gets computed from pyramidal tiers of the system (similar idea as ms had with web.configs)
only we store evrything in SVN wih version control, so the whole clkuster definition is always versioned.

Vy ziplieetes k slovam ne vnikaja to chto vam po-delu otvechajut. (sorri za broken typing)
This is irrelevant. In NFX we havd a concept of a FileSystem, back then I supported WEB and local.

В HOCON есть включение через url(), никто не мешает сделаеть свой протокол с обработчиком. Реализация в akka.net вообще принимает делегат, который позволяет как угодно порезолвить включения.
right, and using C# one can write any software as long as C# runs on a Turing-complete vm :)

it is all about practicality. In windows you can easily map a «local drive» to some remote virtual FS. So what?
This is VERY far from being an integrated solution that works 99.9%, like we use SVNFIleSystem — it only has 300 lines of code
but guess what — it has never ever failed me.
Что мне делать, если мне нужен не SVN, а Git? Я сильно выиграю от того, что у вас есть «концепция файловой системы»?

Интегрированные решения хороши ровно до тех пор, пока в них есть все нужные кусочки. Как только возникает необходимость такое решение в одном месте расширить, а в другом поправить, его интегрированность начинает играть ему во вред.
yes you will gain a lot, because nothing will change but 1 line in config:
_include{ file="/path/to/your/file" fx{ type=«NFX.IO.SVnFileSystem, NFX.Webl» params{...your connect strings..}}}

_include{ file="/path/to/your/file" fx{ type=«NFX.IO.GITFileSystem, NFX.GIT» params{...your connect strings..}}}

btw GIT is not in NFX oper source base, because it was needed only for one closed-source project where GIt is exclusive

Разрабатывать эту «файловую систему» кто будет?

(Потому что с точки зрения самого конфиг-файла решение в hocon ничем не отличается: было include svn://path, стало include git://path)
Its already there for everything I need.
If you have XYZ file system then you need to implement it? no?
others will miraculously self-implement? HDFS? ACFS? GDrive?
Я у вас про это и спрашиваю: в чем для меня выигрыш при реализации адаптера для нового хранилища, если сравнить вашу концепцию «файловой системы» и hocon-овский делегат?
v tom chto eto ispolzuetsya v desyatkax nest, takix kak ustanoivka programmnogo obespecheniya na servera.
vy vse pytaetes dokazat chto u vas ne Unistack i vy s etim happy.
Ya i ne spory

u vas vyigrish budet togda kogda vy poimete chto pishete odno i tozhe 25 raz v kajdom proekete na 3x yazikax i 10 formatax… vot poka eto ne eknet v grudi — to NFX eto ujasniy framework ot kotorogo tolko odna golovnaja bol
v tom chto eto ispolzuetsya v desyatkax nest, takix kak ustanoivka programmnogo obespecheniya na servera.

Да какая мне разница, где это используется, мне мою задачу надо решить.

vy vse pytaetes dokazat chto u vas ne Unistack i vy s etim happy.

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

u vas vyigrish budet togda kogda vy poimete chto pishete odno i tozhe 25 raz v kajdom proekete na 3x yazikax i 10 formatax…

Не пишу. Как раз благодаря тому, что если задачу можно делегировать сторонней библиотеке — она делегируется, и я об этом больше не думаю. А бойлерплейт неизбежен, его просто может быть меньше или больше.

Понимаете ли, беда обсуждаемого поста в том, что заголовок нам говорит про то, как конфигурация влияет на приложение, а сам пост — про то, как NFX влияет на приложение. Оставив в стороне вопрос, надо ли решать описанную задачу с помощью конфигурации, мы встаем перед вопросом: а что такого уникального в NFX для данной задачи, с чем не справились бы общепринятые решения?

Ну да, System.Configuration для этого нездорово громоздок, с этим никто не спорит. Но любое другое решение, позволяющее сериализовать и прочитать граф, справится на ура. XML? Да (писать много буков, правда). JSON? Да. YAML? Да.

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

foreach(var snode in node[CONFIG_SERIALIZERS_SECTION].Children.Where(cn => cn.IsSameName(CONFIG_SERIALIZER_SECTION)))
{
  var item = FactoryUtils.Make<Serializer>(snode, args: new object[]{this, snode});
  m_Serializers.Register( item  );
}
ya razve govoril chto HOCON ujasen? zamette, oni tozhe uzajut non-MS shit :)

no mne-to on zachem? I have tons of software written and running in production making money…
If you dont like NFX, thats fine…
however many people want to know the alternatives to MS stack.
HOCON is a good one, so is NFX
Каждый пост про NFX превращается в срач между lair и адептами NFX.
Причем настолько интересный, что статья уходит на второй план.

У меня практичный вопрос, где-нибудь есть feature comparison table между NFX и ServiceStack? Имхо это две стороны одного велосипеда, и хочется узнать у какого из них звоночек громче.
Насколько знаю, нет такого сравнения. Есть, к примеру, сравнение ServiceStack с WCF.
Если по делу, то есть очень интересное видео про одно приложение NFX (для кэша, с какими-то сумасшедшими заявленными числами). Я сейчас как раз гоняю тесты из этого видео, (который на GitHub, лежит в WinFormsTest тесте).
есть очень интересное видео про одно приложение NFX (для кэша, с какими-то сумасшедшими заявленными числами)

Да про это и пост на хабре есть.
ne dumaju chto takoi comparison nujen ili daje vozmojen. ServiceStack ochen malo imeet otnosheniya k NFX.
Naprimer v NFX net ORM po opredeleniju — eto sovsem drugaja metodologiya.
Ya ne sporju chto SrviceStack xorosho sdelanniy framework, esho est Castle, Lotka, NSpring i shtuk 10 drugix.
Vse oni v chem to peresekautysa, gde-to rasxodyatsya.
NFX voobshe tyt ne podxodit dlya sravneniya, on ne prednaznachen dlya «hire any 25 developers who know whats cool»
V NFX net ni odnoi «cool» fishki, ni odnogo buzworda.
Eto tem interesno kto ponimaet kak rabotaet motor vnutri

Only those users with full accounts are able to leave comments. Log in, please.