Странная какая-то статья. Как будто-бы Net Core это не язык программирования, а какая-то закрытая система, к которой как-то нужно подлаживаться. Но нет, там не нужно ничего дорабатывать, нужно просто написать так, как нужно, и все, будь то свой middleware, service filter или action filter. Обычно на любую интеграцию у меня уходит пара дней, без команды и мозговых штурмов.
EF в C# далеко не только маппер. Например, трекер, первую очередь. Производительность тяжёлых, с точки зрения времени исполнения на сервере, запросов EF и чистого SQL равны. Для сложных запросов, для которых EF требуется больше, чем нужно трипов на сервер или избыточное количество информации локально, используем stored procedures, которые тоже замечательно мапятся EF. "Обычные", средние со всех сторон запросы, EF делает более чем оптимально, нет причин заботиться о том, что там под капотом. Наоборот, я иногда подглядываю, как это сделала EF. Для очень лёгких запросов, когда скорость их исполнения важна, да, у сырого SQL преимущество, но в реальности такие ситуации встречаются крайне редко. Короче , имхо дискуссия ни о чем. И ORM и чистый SQL имеют право на жизнь. Это как спорить, что лучше , if или switch
Если честно, я не понимаю смысл таких статей. Это и не обзор архитектуры и стратегии, и это не детальный разбор какой-то конкретной темы. Больше смахивает на дневник разработчика, понятный только ему. Какие-то непонятные названия переменных и концептуальный npm install на целый абзац :) Некоторые темы из перечисленных мне неплохо знакомы, и я вообще не понимаю, что хотел сказать автор и зачем. А на выходе фактически "Hello, World".
Странная какая-то статья. Как будто-бы Net Core это не язык программирования, а какая-то закрытая система, к которой как-то нужно подлаживаться. Но нет, там не нужно ничего дорабатывать, нужно просто написать так, как нужно, и все, будь то свой middleware, service filter или action filter. Обычно на любую интеграцию у меня уходит пара дней, без команды и мозговых штурмов.
EF в C# далеко не только маппер. Например, трекер, первую очередь. Производительность тяжёлых, с точки зрения времени исполнения на сервере, запросов EF и чистого SQL равны. Для сложных запросов, для которых EF требуется больше, чем нужно трипов на сервер или избыточное количество информации локально, используем stored procedures, которые тоже замечательно мапятся EF. "Обычные", средние со всех сторон запросы, EF делает более чем оптимально, нет причин заботиться о том, что там под капотом. Наоборот, я иногда подглядываю, как это сделала EF. Для очень лёгких запросов, когда скорость их исполнения важна, да, у сырого SQL преимущество, но в реальности такие ситуации встречаются крайне редко. Короче , имхо дискуссия ни о чем. И ORM и чистый SQL имеют право на жизнь. Это как спорить, что лучше , if или switch
Если честно, я не понимаю смысл таких статей. Это и не обзор архитектуры и стратегии, и это не детальный разбор какой-то конкретной темы. Больше смахивает на дневник разработчика, понятный только ему. Какие-то непонятные названия переменных и концептуальный npm install на целый абзац :) Некоторые темы из перечисленных мне неплохо знакомы, и я вообще не понимаю, что хотел сказать автор и зачем. А на выходе фактически "Hello, World".