Может потому, что моногейм не лучшее решение, а не Xamarin? Знаю несколько игр, написаных на Xamarin (не MG) которые работают очень шустро (и новые фичи в них добавляются очень быстро сразу на все платформы ибо C#).
Не нещадно тормозящий Electron-редактор появился впервые у майкрософта в виде VSO. 10 вкладок, Notepad++: 5 МБ памяти; 10 вкладок, VSO: 500 МБ памяти.
А что будет с таким редактором на WPF? :-) Сколько секунд он будет запускаться, жрать памяти и насиловать видеокарту?
PS: редактор на WPF — вытекут глаза от шрифтов.
Виноват, перепутал мкс с мс, корретные результаты в мкс такие (что все равно много меньше чем у вас для Invoke):
с UI потока: 0.2 мкс
с потока тредпула: 0.4 мкс
роекты, на которых был выбран именно этот подход к написанию UI были самыми приятными из всех, в которых я участвовал. К несчастью, им мало кто пользуется. Но пользуются. Антивирусы Norton, Yahoo Messenger, Nod32, EverNote, линейка продуктов Mozilla (с оговорками).
Что забавно, Evernote сперва был написан на WPF, но авторы устали бороться с его тормозами.
1 — UserControl'ы в принципе зло, лучше писать на кастом контролах т.к. проблема с RD применима ко всему XAML'у UC в целом.
2 — не имеет отношение к WPF, к тому же тот же Resharper подскажет, что не стоит лямбдой отписываться
3 — интересно. хотя зачем делать Mode=TwoWay для свойства у класса, не реализующего INPC?
5 —
при переименовании свойств можно забыть изменить константы в условиях
опять же, решарпер выскажет подозрения при переименовании и предложит переименовать эту константу тоже. А вообще такой код конечно плохой, лучше использовать RX :-)
6 —
Время, затраченное Dispatcher.Invoke сверх «полезной» нагрузки при вызове из того же потока, к которому принадлежит Dispatcher — 0.2 мкс на один вызов.
Тот же показатель, но при вызове из другого потока — 26 мкс на вызов.
Надеюсь, вы понимаете что есть еще и BeginInvoke, но всё же мои тесты с Invoke:
с UI потока: 0.0002 мкс
с потока тредпула: 0.0004 мкс (специально перевел 4000 тиков в микросекунды, чтобы показать разницу с вашими)
ЧЯДНТ? Вот так тестил: gist.github.com/EgorBo/0659e8e1b42ea72190b7
8 — я бы ваш ModalDialogHelper переписал на TaskCompletionSource'ы без вот такой жести: Task.Run(() => waitEvent.WaitOne()); и AutoResetEvent'ов в целом.
Моё мнение — WPF не нужен: в интерпрайзах перешли уже на веб давно (а неинтерпрайз на нем и не писали особо), а wpf так и остался тормозным, с мыльными шрифтами на офисном dpi и его не обновляли уже лет 5 (блог wpf команды через 5 лет бездействия проснулся 4 месяца назад с какими-то невнятными обещаниями и опять заснул) с монструозным XAML. Если уж надо делать неинтерпрайзный клиент чего-то нужного для десктопа, то современные реалии требуют и поддержку Mac OS, с чем у WPF чуть лучше чем никак.
Я так понимаю вас испугал в Rust список шаблонных методов типа skip,take, max, zip — почти 1 в 1 тоже самое что содержиться в классе Enumerable С# (и stream для java) который linq. Так после реализации их в том же Enumerable они не кажутся мне страшными в итераторе в Rust.
Объективно говоря, C# как язык — это java 8 + пяток простых сахарных помогалок. Многие сходяться во мнении, что экосистема явы имеет более высокий порог вхождения, чем C#. Ну а тут, судя по графику, C# сложнее java в почти 4 раза.
Ну вот вы вроде сами понимаете, что отношение кол-ва репозиториев на гитхабе к кол-ву вопросов на SO очень и очень слабо коррелирует с сложностью языка, возможно даже слабее чем отношение популяции канадских бобров к средней зарплате в РФ.
>>EF — это не репозиторий.
Ну чем же DbContext не репозиторий? Классик, который наружу выставляет коллекции _доменных_ объектов с которыми можно работать как с обычнми коллекциями + немного UoW.
>>DO не должно иметь бизнес логику, это противоречит идее DO. DO — это такие же структуры, только с connected state.
Кто сказал? Вот к примеру Фаулер сказал, что анемичная доменная модель — анти-паттерн: www.martinfowler.com/bliki/AnemicDomainModel.html
SOLID — отличная вещь, он позволяет обозвать любой код говнкодом ибо невозможно написать серьезный проект 100% следуя SOLID. Где-нибудь да найдется классик, у которого будет больше одной ответственности к примеру :-).
«в большинстве случаев» — слишком абстрактно (кол-во однокоренных слов к «абстракция» зашкаливает в этом треде: Р). Лично участвовал в проекте, в котором EF меняли на nHibernate и благодаря абстракции это прошло безболезненно.
А что будет с таким редактором на WPF? :-) Сколько секунд он будет запускаться, жрать памяти и насиловать видеокарту?
PS: редактор на WPF — вытекут глаза от шрифтов.
с UI потока: 0.2 мкс
с потока тредпула: 0.4 мкс
Что забавно, Evernote сперва был написан на WPF, но авторы устали бороться с его тормозами.
2 — не имеет отношение к WPF, к тому же тот же Resharper подскажет, что не стоит лямбдой отписываться
3 — интересно. хотя зачем делать Mode=TwoWay для свойства у класса, не реализующего INPC?
5 — опять же, решарпер выскажет подозрения при переименовании и предложит переименовать эту константу тоже. А вообще такой код конечно плохой, лучше использовать RX :-)
6 —
Надеюсь, вы понимаете что есть еще и BeginInvoke, но всё же мои тесты с Invoke:
с UI потока: 0.0002 мкс
с потока тредпула: 0.0004 мкс (специально перевел 4000 тиков в микросекунды, чтобы показать разницу с вашими)
ЧЯДНТ? Вот так тестил: gist.github.com/EgorBo/0659e8e1b42ea72190b7
8 — я бы ваш ModalDialogHelper переписал на TaskCompletionSource'ы без вот такой жести: Task.Run(() => waitEvent.WaitOne()); и AutoResetEvent'ов в целом.
Моё мнение — WPF не нужен: в интерпрайзах перешли уже на веб давно (а неинтерпрайз на нем и не писали особо), а wpf так и остался тормозным, с мыльными шрифтами на офисном dpi и его не обновляли уже лет 5 (блог wpf команды через 5 лет бездействия проснулся 4 месяца назад с какими-то невнятными обещаниями и опять заснул) с монструозным XAML. Если уж надо делать неинтерпрайзный клиент чего-то нужного для десктопа, то современные реалии требуют и поддержку Mac OS, с чем у WPF чуть лучше чем никак.
Ну чем же DbContext не репозиторий? Классик, который наружу выставляет коллекции _доменных_ объектов с которыми можно работать как с обычнми коллекциями + немного UoW.
Кто сказал? Вот к примеру Фаулер сказал, что анемичная доменная модель — анти-паттерн: www.martinfowler.com/bliki/AnemicDomainModel.html
Идеальная архитетура выглядет как-то так:[/sarcasm]
EmployeePersistenceObj -> EmployeeDomainObj -> EmployeeDto — [transport] — EmployeeDto -> EmployeeClientDomainObj -> EmployeeViewModel
PS: минусую не я :-)