HUJG 2 мар 2018 в 10:20

EF Core

23 мин

101K

.NET*C#*

Из песочницы

+23

Комментарии 39

AgentFire 2 мар 2018 в 11:21

Если честно, я в принципе не вижу смысла в full-stack'e. Даже чистый backend я иногда разбиваю на 2 приложения, если логика их работы того подразумевает.

В чем заключается и чем плоха эта зловещая пропасть между беком и фронтом? Кто мешает программисту писать раздельный код, вместо фулстека, используя больше узконаправленных преимуществ каждого из подходов? Смотрите эти и другие холивары под этим комментом -_-

posledam 2 мар 2018 в 13:20

Мне кажется вы разделение f/b перепутали с модульностью. И как можно не увидеть смысла в том, что единая система разрабатывается, работает, поставляется и развёртывается единым целым, единой командой. Каждая фича доставляется сразу, а не не наполовину, и не требует согласования команд разработчиков. Тут лишь надо проставить акценты, кто как считает правильным. В зависимости от проекта, или на уровне собственных религиозных убеждений.

Tantrido 2 мар 2018 в 14:12

чем плоха эта зловещая пропасть между беком и фронтом?

В зарплате: 20$/час и 50 — есть разница? :)

TimeCoder 2 мар 2018 в 21:09

А у кого из них 50?

Tantrido 2 мар 2018 в 22:16

У full-stack-а выше конечно.

TimeCoder 3 мар 2018 в 06:17

А, ну это да, я подумал вы сравнивали фронт и бэк между собой.

TyVik 2 мар 2018 в 11:24

Ни для кого не секрет, что .net сейчас используется в большинстве случаев как инструмент бэкенд разработки

Как-то уж сильно категорично.

Simplevolk 6 апр 2018 в 10:50

И немножечко холиварно… Но лично я за .Net. Приятно видеть, как экосистема развивается.

mayorovp 2 мар 2018 в 11:28

Было бы еще неплохо серверный рендер прикрутить, пакет Microsoft.AspNetCore.SpaServices это умеет делать.

И с маршрутами разобраться: маршрут Default тут точно лишний, он дублирует spa-fallback. А маршрут DefaultApi зачем-то дублируется атрибутами, что-то одно тут тоже лишнее.

mayorovp 2 мар 2018 в 11:35

И еще: зачем в DefaultApi нужна в конце приписка /{id?}, если выбранный способ задания маршрутов в js (constants = { ... }) не поддерживает параметры в маршрутах?

HUJG 2 мар 2018 в 13:23

Ага, спасибо, поправил.

mayorovp 2 мар 2018 в 15:29

Э… а куда теперь spa-fallback делся?

HUJG 2 мар 2018 в 16:06

Он есть, просто по законам жанра мы его только в части 2. Фронтенд подключаем.

mayorovp 2 мар 2018 в 16:09

А, нашел. А где серверный рендер?

HUJG 2 мар 2018 в 16:49

Я попробую дописать в статью, но на это нужно больше времени. Пока оставлю там ссылку. docs.microsoft.com/en-us/aspnet/core/client-side/spa-services#server-side-prerendering

Smerig 2 мар 2018 в 12:20

без tsx не модно.

slaFFik 2 мар 2018 в 14:28

но для бэковой разработки, все же, .net бесспорный лидер.

Это в какой, интересно, вселенной? Явно в какой-то своей собственной, альтернативной. А в нашей данная категоричность неуместна. Особенно учитывая, какой язык возглавляет список наиболее часто используемых языков программирования для бэкэнда.

HUJG 2 мар 2018 в 14:55

Имелось ввиду по сравнению с javascript. Но судя по комментариям приставку «бес» надо убирать из статьи. :)

Novikofff 2 мар 2018 в 19:28

А так же фразу горячо любимую Visual Studio тоже можно записать менее категоричную.

-1

НЛО прилетело и опубликовало эту надпись здесь

mayorovp 2 мар 2018 в 19:11

Причем тут свалка? Обе части — фронтэнд и бакэнд должны после развертывания оказаться в одном и том же месте. Логично что для этого они должны быть в одном проекте.

CHROMIGO 2 мар 2018 в 21:30

Спасибо за статью, написано довольно просто и понятно.
Почти со всем вышеописанным знаком, но после прочтения вне не перестаю удивляться сколько всего сейчас нужно знать чтобы писать fullstack веб приложение на новых технологиях. И ведь это все как то в голове укладывается.

VVit1 2 мар 2018 в 23:03

А можно спросить какое преимущество даёт на беке использование асинков?

-1

HUJG 2 мар 2018 в 23:06

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

VVit1 3 мар 2018 в 06:27

Это не совсем так. Обработка реквеста проходит по своему пайпу и никаких других реквестов там быть не может. В данном случае кроме переусложнения понимания логики выполнения (асинки не так просты как это может показаться и не панацея для всех случаев жизни) и растраты ресурса на лишние переключения контекста ничего другого здесь не получим.

-4

HUJG 3 мар 2018 в 08:52

Мне кажется здесь вы немного переусложняете и сваливаете все в одну кучу и обработку pipeline реквеста и асинки. Ничего сверх сложного в асинках нет, с точки зрения их использования, и есть вполне определенный набор кейсов когда их стоит применять, и не совсем понятно как это связано с пайпами.

mayorovp 3 мар 2018 в 09:39

Что вы понимаете под «своим пайпом» для запроса? Я не видел в коде ASP.NET никаких выделенных пайпов.

donRumatta 7 мар 2018 в 15:13

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

mayorovp 7 мар 2018 в 16:47

Транспортный уровень отслеживает. Если это сокеты — то там используется IOCP (Input-Output Completion Port), и есть один или несколько потоков пула которые ждут событий из этого порта. Однако процессорного времени эти ждущие потоки не тратят, да и количество таких потоков от количества активных запросов никак не зависит.

donRumatta 7 мар 2018 в 23:45

Место встречи изменить нельзя(= Спасибо за инфу, решил уже пролистать курс ОС, а то или невнимательно слушал в свое время, или нам глубоко не объясняли подробности асинхронщины.

dmitry_dvm 3 мар 2018 в 00:37

А зачем обертки для репозитория, почему в startup сразу не используется ef с внедрением в контроллеры через di? Какие преимущества у этого подхода? Немного сумбурно спрашиваю, имею в виду зачем дублировать методы контроллера в обертках репы, когда можно сразу запрашивать нужное?

HUJG 3 мар 2018 в 09:05

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

HackerDelphi 5 мар 2018 в 08:20

Уже были даже на Хабре статьи — EF отлично умеет мокать сам себя, через MemoryDb — там моки из коробки… Кроме того EF уже реализует свитере Repository. IMHO, написание отдельного репозитария в данном случае — over engineering....

HackerDelphi 5 мар 2018 в 08:21

Свитере = паттерн. Автозамена...

DonAlPAtino 12 мар 2018 в 16:00

>>В строке 1 мы включаем поддержку webpack, теперь у нас не будет болеть голова за сборку клиентских ресурсов (app.UseWebpackDevMiddleware(); в Startup.cs)
билдимся и получаем…
«Webpack dev middleware failed because of an error while loading 'aspnet-webpack'. Error was: Error: Cannot find module 'aspnet-webpack'»
где-то еще какую-то фронт/webpack магию не прописал?

DonAlPAtino 12 мар 2018 в 17:42

npm i aspnet-webpack --save-dev
publicPath: path.resolve(__dirname, bundleFolder) в webpack.config.js

это за неделю после публикации что ли добавилось?

HUJG 12 мар 2018 в 18:50

Не совсем понял, что добавилось за неделю после публикации?
Да, чтобы UseWebpackDevMiddleware заработал из SpaServices, нужно поставить пакет aspnet-webpack и прописать publicPath в конфиге, можно и без path.resolve, все пути зарезолвятся. Но вроде это было в статье.

Ekkeir 25 июн 2018 в 19:07

Вопрос к

    return (dispatch) => {
        let queryTrailer = '?pageIndex=' + pageIndex;
        if (tag) {
            queryTrailer += '&tag=' + tag;
        }

Есть ли способ проброса запросов в ASP.Net, который бы не включал использование строковых литералов? Если быть более точным, можно ли как-то связать (не обязательно буквально) ASP со JS так, чтобы при изменении на стороне ASP (например, в имени параметра или пути) можно было очевидным образом найти все места в js коде, которые обращаются к соответствующей функции и которые, соответственно, теперь нужно править?

mayorovp 26 июн 2018 в 10:57

Да, через OpenAPI (Swagger). Нужно при сборке сначала сгенерировать OpenAPI-описание API, а потом по этому описанию — клиент на typescript.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Показать лучшие за всё время