Да и нефункциональные требования могут накладывать отпечаток: описывая развесистые системы неплохо бы понимать, какие технические подробности можно опустить на этом уровне абстракции, а какие - критичны с точки зрения понимания бизнеса и их нужно тащить наверх. В коде этой информации взяться неоткуда.
Пока проект работает сколь либо похоже на DDD - это может работать. Но если логические модели бизнес-процессов разъезжаются с техническими моделями, делая последние однобокими проекциями первых, то тут нейронки разве что галлюцинациями помогут.
Например: не самая простая система, которая позволяет много вольностей по “поломке” данных (нарушения инвариантов) в угоду гибкости разруливания нестандартных ситуаций (aka впихивание невпихуемого и натягивание реальных земных сов на идеальные лунные глобусы), в расчете на опытного оператора, который знает, за какие ручки в какой ситуации дёргать => добрая часть бизнес-правил стандартного/штатного флоу в коде не отражается. Если бизнес жопится на общую описательную документацию, то и на полновесные e2e, требующие активной поддержки, расчитывать не приходится.
Изученный чужой опыт - тоже опыт. Чем больше насмотренность по проектам, по их проблемам и способам их решений, тем больше личный багаж шаблонов SD. Другое дело, что не в каждом проекте найдутся сложные нефункциональные требования, вроде нагрузок и высокой доступности. Не каждый стартап доживет и переживет масштабирование, поэтому тут скорее путь в бигтехи с налаженными процессами с работой за опыт или в теорию - доклады с конференций и профильная литература, вроде книги с кабаном.
Операционная система - это вообще история про монопольный контроль ресурсов, разного рода изоляции, абастракции и прочие рантаймовые проверки. Эти вещи почти всегда оплачиваются производительностью, в сравнении с программированием на голом железе.
Согласен, технически возможность создавать потоки действительно есть, но там же будут разные рантаймы, общей памяти ни у потоков, ни у корутин все равно нет - нельзя передавать ссылки на объекты между потоками.
View в MVC - это презентационный слой для данных, визуальным он может быть, но не обязан. REST API своему клиенту могут презентовать данные в виде JSON - фронтенду или другому (микро)сервису. Визуализируются они дальше или нет - не важно.
В ASP.NET Core средства создания REST API лежат в сборке Microsoft.AspNetCore.Mvc.Core, поэтому логично было бы считать их частью ASP.NET Core MVC-сабфреймворка. Раньше этому у MS было отдельное название - Web API, а сейчас в документации скупое Controller-based APIs.
Это значит, что ASP и ASP.NET - разные технологии. Ссылку я привел выше.
У актуального дотнета уже несколько лет нет слова Core в названии
У дотнета - уже нет, а у библиотек и фреймворков - так и осталось. ASP.NET Core, EF Core и т.п.
У MS всю дорогу проблемы с неймингом =3
MVC - это шаблон проектирования Model-View-Controller, и я затрудняюсь представить, кто и как пишет с его помощью микросервисы.
В чем именно тут затруднение? Микросервисы накладывают ограничения на архитектурные паттерны? Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?
ASP, еще до дотнета который? Нет, речь идет об актуальном ASP.NET Core MVC, хотя автор в посте по почему-то отбросил слово "Core", но из контекста понятно, что речь идет не про оригинальный ASP.NET MVC под .NET Framework.
JS Interop — это головная боль. Да, можно использовать JS-библиотеки, но там, где TypeScript подсвечивает синтаксис и проверяет типобезопасность на этапе компиляции, в Blazor все проверки смещаются в рантайм
Если говорить именно про библиотеки на JS, то TS будет полагаться на декларации контрактов (*.d.ts), которые в рантайме так же могут разъехаться с реализацией. При том TS, как известно, не силен рантаймовыми проверками, в отличие от.
На MVC в том числе делают микросервисы. Кроме того, сейчас MS ативно форсит более аскетичный Minimal API для этих целей, но этот подход еще не победил.
Там нет минорных версий, вообще такое понятие в описаниях релизов не фигируриует. Срок поддержки - это чисто административное решение, можно было хоть каждый LTSом сделать.
Лично я лоялен вакансиям с Go, но пока максимум, что встречал в тандеме с дотнетом - это горячие инфраструктурные штуки. Но чтобы кто-то брался переписывать ядро бизнес-логики - такого не видел. У меня поиск не репрезентативен, особенно по тенденциям за рубежом, но прям тотальных изменений пока на горизонте не видно.
JS - это просто целевая платформа для TS =3 Львиная часть семантики типов никак не маппится на JS, поэтому линтить там нечего.
Да и нефункциональные требования могут накладывать отпечаток: описывая развесистые системы неплохо бы понимать, какие технические подробности можно опустить на этом уровне абстракции, а какие - критичны с точки зрения понимания бизнеса и их нужно тащить наверх. В коде этой информации взяться неоткуда.
Пока проект работает сколь либо похоже на DDD - это может работать. Но если логические модели бизнес-процессов разъезжаются с техническими моделями, делая последние однобокими проекциями первых, то тут нейронки разве что галлюцинациями помогут.
Например: не самая простая система, которая позволяет много вольностей по “поломке” данных (нарушения инвариантов) в угоду гибкости разруливания нестандартных ситуаций (aka впихивание невпихуемого и натягивание реальных земных сов на идеальные лунные глобусы), в расчете на опытного оператора, который знает, за какие ручки в какой ситуации дёргать => добрая часть бизнес-правил стандартного/штатного флоу в коде не отражается. Если бизнес жопится на общую описательную документацию, то и на полновесные e2e, требующие активной поддержки, расчитывать не приходится.
Всё, что нужно знать о надежности рандомных сервисов в интернете)
Наоборот же: отделена логика инициализации состояния объекта в конструкторе, а описание функций - вынесено отдельно.
Не вижу использования свойства
prototypeв примере с функцией-конструктором, это ведь не эквивалентный код.Бонус - это синтаксис, а сами аксессоры можно добавлять через
Object.defineProperty.Изученный чужой опыт - тоже опыт. Чем больше насмотренность по проектам, по их проблемам и способам их решений, тем больше личный багаж шаблонов SD. Другое дело, что не в каждом проекте найдутся сложные нефункциональные требования, вроде нагрузок и высокой доступности. Не каждый стартап доживет и переживет масштабирование, поэтому тут скорее путь в бигтехи с налаженными процессами с работой за опыт или в теорию - доклады с конференций и профильная литература, вроде книги с кабаном.
Операционная система - это вообще история про монопольный контроль ресурсов, разного рода изоляции, абастракции и прочие рантаймовые проверки. Эти вещи почти всегда оплачиваются производительностью, в сравнении с программированием на голом железе.
За счет чего операционка должна ускоряться от версии к версии?
Зумеры изобрели Dial-up?😁
Согласен, технически возможность создавать потоки действительно есть, но там же будут разные рантаймы, общей памяти ни у потоков, ни у корутин все равно нет - нельзя передавать ссылки на объекты между потоками.
Там же по факту костыли на многопроцессносности, а не многопоточность. Нет возможности прямо в том же процессе сделать поток и управлять им.
Бойан
View в MVC - это презентационный слой для данных, визуальным он может быть, но не обязан. REST API своему клиенту могут презентовать данные в виде JSON - фронтенду или другому (микро)сервису. Визуализируются они дальше или нет - не важно.
В ASP.NET Core средства создания REST API лежат в сборке
Microsoft.AspNetCore.Mvc.Core, поэтому логично было бы считать их частью ASP.NET Core MVC-сабфреймворка. Раньше этому у MS было отдельное название - Web API, а сейчас в документации скупое Controller-based APIs.Это значит, что ASP и ASP.NET - разные технологии. Ссылку я привел выше.
У дотнета - уже нет, а у библиотек и фреймворков - так и осталось. ASP.NET Core, EF Core и т.п.
У MS всю дорогу проблемы с неймингом =3
В чем именно тут затруднение? Микросервисы накладывают ограничения на архитектурные паттерны? Или что "View" может быть не только куском готового HTML, но и JSON-моделькой?
ASP, еще до дотнета который? Нет, речь идет об актуальном ASP.NET Core MVC, хотя автор в посте по почему-то отбросил слово "Core", но из контекста понятно, что речь идет не про оригинальный ASP.NET MVC под .NET Framework.
Если говорить именно про библиотеки на JS, то TS будет полагаться на декларации контрактов (*.d.ts), которые в рантайме так же могут разъехаться с реализацией. При том TS, как известно, не силен рантаймовыми проверками, в отличие от.
На MVC в том числе делают микросервисы. Кроме того, сейчас MS ативно форсит более аскетичный Minimal API для этих целей, но этот подход еще не победил.
А какое преимущество в вебе дает интерпретация?
WebSocket против HTTP и полноценный WASM-режим с возможностью делать полноценные PWA.
Там нет минорных версий, вообще такое понятие в описаниях релизов не фигируриует. Срок поддержки - это чисто административное решение, можно было хоть каждый LTSом сделать.
Это буквально означает, что нужно и то, и другое)
Лично я лоялен вакансиям с Go, но пока максимум, что встречал в тандеме с дотнетом - это горячие инфраструктурные штуки. Но чтобы кто-то брался переписывать ядро бизнес-логики - такого не видел. У меня поиск не репрезентативен, особенно по тенденциям за рубежом, но прям тотальных изменений пока на горизонте не видно.