Pull to refresh

Comments 39

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


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

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

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

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

Как-то уж сильно категорично.
И немножечко холиварно… Но лично я за .Net. Приятно видеть, как экосистема развивается.
Было бы еще неплохо серверный рендер прикрутить, пакет Microsoft.AspNetCore.SpaServices это умеет делать.

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

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

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

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

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

Имелось ввиду по сравнению с javascript. Но судя по комментариям приставку «бес» надо убирать из статьи. :)
А так же фразу горячо любимую Visual Studio тоже можно записать менее категоричную.
Откроем командную строку, перейдем в папку, где у нас лежит, созданный в студии .net core web application, и выполним команду npm init.
Вот зачем такую свалку делать?
Приложения под Android и iOS тоже в этот же проект будете запихивать?
Причем тут свалка? Обе части — фронтэнд и бакэнд должны после развертывания оказаться в одном и том же месте. Логично что для этого они должны быть в одном проекте.
Спасибо за статью, написано довольно просто и понятно.
Почти со всем вышеописанным знаком, но после прочтения вне не перестаю удивляться сколько всего сейчас нужно знать чтобы писать fullstack веб приложение на новых технологиях. И ведь это все как то в голове укладывается.
А можно спросить какое преимущество даёт на беке использование асинков?
Ну в данном случае мы ходим в базу за данными и при использовании асинка поток не будет ждать ответа от базы, а вернётся в пул, где сможет заняться чем нибудь полезным, например обработать ещё один реквест.
Это не совсем так. Обработка реквеста проходит по своему пайпу и никаких других реквестов там быть не может. В данном случае кроме переусложнения понимания логики выполнения (асинки не так просты как это может показаться и не панацея для всех случаев жизни) и растраты ресурса на лишние переключения контекста ничего другого здесь не получим.

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

Что вы понимаете под «своим пайпом» для запроса? Я не видел в коде ASP.NET никаких выделенных пайпов.
Немного оффтоп, но как раз сейчас пытаюсь разобраться: кто же отслеживает, что пришел ответ от БД и запускает коллбэк, не выдается ли ему периодически процессорное время, как потоку?
Транспортный уровень отслеживает. Если это сокеты — то там используется IOCP (Input-Output Completion Port), и есть один или несколько потоков пула которые ждут событий из этого порта. Однако процессорного времени эти ждущие потоки не тратят, да и количество таких потоков от количества активных запросов никак не зависит.
Место встречи изменить нельзя(= Спасибо за инфу, решил уже пролистать курс ОС, а то или невнимательно слушал в свое время, или нам глубоко не объясняли подробности асинхронщины.

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

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

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

>>В строке 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 магию не прописал?
npm i aspnet-webpack --save-dev
publicPath: path.resolve(__dirname, bundleFolder) в webpack.config.js

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

Вопрос к


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

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

Да, через OpenAPI (Swagger). Нужно при сборке сначала сгенерировать OpenAPI-описание API, а потом по этому описанию — клиент на typescript.
Only those users with full accounts are able to leave comments. Log in, please.