Comments 21
Самая свежая документация по ASP.NET5 расположена по адресу docs.asp.net/en/latest.
Вот это удручает. Уже сколько времени прошло, а большая часть документации на docs.asp.net это:
This topic hasn’t been written yet!
это наверное потому, что большинство функций могут изменятся и писать документацию сейчас никто не будет. Кроме того, проект открытый и открытый для вклада со стороны, много контента сделано сторонними разработчиками. Сам Microsoft писать подробную документацию к бета-продукту не станет.
Если бы это был не официальная страница MS на хабре, я бы прошел бы мимо вашего сообщения. Но раз уж, есть как есть, придется высказаться. Вы все же не шарашкина контора, которая выпускает впервые свою новую библиотеку и не знает что делать, допиливать бету или писать минимальную доку. На каждом углу вы пишите как здорово VS2015, vNext, ASP.NET 5, MVC и так далее, и как бы намекаете, ребята айда все к нам, даже линукс/мак девы, у нас круто. Вы поменяли полностью все в мире ASP.NET и около него, так что все мои знакомые впервые открыв веб проект, могут только F5 нажать (это единственное что им знакомо). Пишите много статей и видео роликов. И в тоже время на «единственную» официальную документацию вы реально забиваете, со словами: «Сам Microsoft писать подробную документацию к бета-продукту не станет.» Так кто же ее будет писать? Вася Пупкин? Который открыл сырцы с гитхаба. Ваши слова выглядят так, как, мы тут все молодцы до безобразия сделали такой продукт, а вы уже сами как хотите разбирайтесь, нам дела нет до какой то там документации, к пуговицам притензии есть? Тогда просто возникает резонный вопрос, а зачем вы уже пол года кричите, что бы все переходили на ваши новые решения, может сначала сделайте до конца, да про доки не забудьте, а после уже пиартесь, коль не можете найти пару человек в команду, которые бы просто следили за изменениями и оперативно вносили их в документация. Да даже в лично ваших статьях я узнал некоторые моменты, которые на гордом docs.asp.net/en/latest значатся как This topic hasn’t been written yet!
Сор, но ваш ответ просто зацепил за живое. Не так много у многих девов времени, чтобы по крупице собирать информацию про абсолютно новый движок. Хочется все же сесть, прочитать и разобраться со всем, хотя бы минимум необходимым, из одного источника и сделать что либо минимально стоящее (просто руку понабивать).
Сор, но ваш ответ просто зацепил за живое. Не так много у многих девов времени, чтобы по крупице собирать информацию про абсолютно новый движок. Хочется все же сесть, прочитать и разобраться со всем, хотя бы минимум необходимым, из одного источника и сделать что либо минимально стоящее (просто руку понабивать).
UFO just landed and posted this here
Асинхронность — это просто
А что будет, если Delay будет больше чем 100 мс? Например минута или пара? Так чтобы выйти за Timeout со стороны клиента.
а что такое таймаут со стороны клиента? таймаут есть у сервера, как раз тут проблема решается, пул запросов освобождается благодаря асинхронности. Проблему длительных задач решают по другому, ставят в очередь, уведомляют клиента о статусе, процентах выполнения. например, в релаьном времени с помощью signalr
Когда мы заранее знаем, что именно эта операция займет много времени, то да, мы можем использовать очередь задач, статус, процесс выполнения.
Но что если *вдруг* база настолько занята, что ответ от нее летит несколько минут. Клиент все это время будет висеть в ожидании ответа от сервера? Или может быть отдаст код 102?
Но что если *вдруг* база настолько занята, что ответ от нее летит несколько минут. Клиент все это время будет висеть в ожидании ответа от сервера? Или может быть отдаст код 102?
ASP.NET MVC 6 позволяет использовать и другие папки, т.к. ищет их по базовому классу.
Разве он ищет их не просто по имени? Мне казалось, что в mvc 6 можно использовать POCO классы в роли контроллеров.
можно. не по умолчанию. это тема для отдельной статьи.
Не могу с Вами согласиться насчёт не по умолчанию, прямо сейчас создал новый проект, создал там класс
Захожу на http:// localhost:57092/test/test, получаю в ответ «Here we go», видимо всё-таки контроллер теперь ищется только по имени
public class TestController
{
public string Test()
{
return "Here we go";
}
}
Захожу на http:// localhost:57092/test/test, получаю в ответ «Here we go», видимо всё-таки контроллер теперь ищется только по имени
В статье встретил формулировку «не надо нагружать модель лишним кодом».
Но в рекомендациях к другим MVC Фреймворкам очень часто вижу обратный пункт «все должно быть в модели, метод контроллера должен быть прост и минимален».
Для себя хочу понять «идеологию» этих двух утверждений, почему используется две таких «полярных» идеологии, хотя мне кажется логичным подход, что модель должна иметь свойства, методы, что максимально ресурсоемкие задачи должны быть вынесены вообще на самый мощный, обычно это sql сервер. а логика работы таки да, должна быть в контроллере.
Спасибо за статью, судя по ней с mvc5 не очень много поменялось, но все равно нет описания о том как использовать bower, grunt, css процессоры, т.к view и его генерация — это достаточно ресурсоёмкая задача, и минимизировать код того же bootstrap'а для выкусывания лишнего и сборки только нужных компонентов — не простая для новичков задача
Но в рекомендациях к другим MVC Фреймворкам очень часто вижу обратный пункт «все должно быть в модели, метод контроллера должен быть прост и минимален».
Для себя хочу понять «идеологию» этих двух утверждений, почему используется две таких «полярных» идеологии, хотя мне кажется логичным подход, что модель должна иметь свойства, методы, что максимально ресурсоемкие задачи должны быть вынесены вообще на самый мощный, обычно это sql сервер. а логика работы таки да, должна быть в контроллере.
Спасибо за статью, судя по ней с mvc5 не очень много поменялось, но все равно нет описания о том как использовать bower, grunt, css процессоры, т.к view и его генерация — это достаточно ресурсоёмкая задача, и минимизировать код того же bootstrap'а для выкусывания лишнего и сборки только нужных компонентов — не простая для новичков задача
>максимально ресурсоемкие задачи должны быть вынесены вообще на самый мощный, обычно это sql сервер
Тут есть большая потенциальная проблема. Дело в том, что масштабировать SQL-сервер на порядок сложнее, чем масштабировать веб-приложение. Серверов с кодом можно рядом поставить очень просто. А вот поставить рядом с текущим SQL-сервером такой же второй — нетривиальная задача (частично зависит от типа SQL-сервера).
Я решаю эту дилемму, о которой вы говорите, так. Если модель имеет какой-то код, который относится только к этой самой модели (не нужны данные из других моделей), то код в самой модели. Если какой-то код связан с несколькими моделями, то он должен быть в специальных классах (но не в контроллерах!), так называемых сервисах. А контроллер я делаю «тонкий», в нём пару вызовов сервисов и/или моделей.
Тут есть большая потенциальная проблема. Дело в том, что масштабировать SQL-сервер на порядок сложнее, чем масштабировать веб-приложение. Серверов с кодом можно рядом поставить очень просто. А вот поставить рядом с текущим SQL-сервером такой же второй — нетривиальная задача (частично зависит от типа SQL-сервера).
Я решаю эту дилемму, о которой вы говорите, так. Если модель имеет какой-то код, который относится только к этой самой модели (не нужны данные из других моделей), то код в самой модели. Если какой-то код связан с несколькими моделями, то он должен быть в специальных классах (но не в контроллерах!), так называемых сервисах. А контроллер я делаю «тонкий», в нём пару вызовов сервисов и/или моделей.
Про SQL сервер я говорил как раз в контексте «толстых запросов» к БД. Например, насколько я знаю, один из идиотизмов 1с был в том, что она сначала получает ВСЕ данные с sql сервера на клиент, а потом начинает пытаться это все обработать на мелком тонком клиенте или слабенькой рабочей станции, хотя 80% этих задач можно решить через view/function на SQL сервере гораздо более оптимально и быстрее, чем мучать для этого слабенькие офисные машинки.
Понятно, что «толстые задачи» не относящиеся к БД, например обработка графических файлов, должна выполняться асинхронно на более другом сервисе фоновых воркеров.
Понятно, что «толстые задачи» не относящиеся к БД, например обработка графических файлов, должна выполняться асинхронно на более другом сервисе фоновых воркеров.
> а логика работы таки да, должна быть в контроллере.
Давайте посмотрим шире и уйдет от элементарных демо-приложений из 1-2 контроллеров. Как правило у вас вы будете создавать n-tier (ну или onion) решение, где у вас будет отдельный бизнес-слой. Веб-приложение вообще в этом случае это просто уровень UI. И чем меньше в нем именно бизнес-логики, тем лучше (для сопровождения и модификации в дальнейшем).
Я даже склонен рассматривать модели MVC приложения как ViewModel в рамках всего приложения. Т.е. контроллер знает что за данные запросили, знает где их взять (в каких сервисах) и формирует некую модель для данной страницы (ведь не всегда то, что надо отобразить 1 в 1 совпадает с моделями BL, не редко это набор из BL).
> но все равно нет описания о том как использовать bower, grunt, css процессоры
Все еще впереди :) Кстати, в последних сборках в проект уже по умолчанию включается gulp, а не bower.
Давайте посмотрим шире и уйдет от элементарных демо-приложений из 1-2 контроллеров. Как правило у вас вы будете создавать n-tier (ну или onion) решение, где у вас будет отдельный бизнес-слой. Веб-приложение вообще в этом случае это просто уровень UI. И чем меньше в нем именно бизнес-логики, тем лучше (для сопровождения и модификации в дальнейшем).
Я даже склонен рассматривать модели MVC приложения как ViewModel в рамках всего приложения. Т.е. контроллер знает что за данные запросили, знает где их взять (в каких сервисах) и формирует некую модель для данной страницы (ведь не всегда то, что надо отобразить 1 в 1 совпадает с моделями BL, не редко это набор из BL).
> но все равно нет описания о том как использовать bower, grunt, css процессоры
Все еще впереди :) Кстати, в последних сборках в проект уже по умолчанию включается gulp, а не bower.
«Все еще впереди :) Кстати, в последних сборках в проект уже по умолчанию включается gulp, а не bower.»
Вы, наверно, хотели сказать не bower, а grunt — потому что gulp и bower, насколько я знаю вещи разного плана — первый таск-менеджер, а второй менеджер пакетов.
Если будете рассматривать тему фронт-енда, то хотелось бы рассмотреть проблему привязки (binding) задач (grunt и gulp) к конфигурации (debug, release и т.д.) билда проекта — если это вообще на данном этапе решаемо. Надеюсь что можно как-то программно вызывать запуск задач — тогда настройку какие задачи запускать, можно делать в Stаrtup файле. Если же binding задач к событиям, вещь в себе и доступна только из контекстного меню Task Runner Explorer — то это конечно очень грустно — задачи для прод и девелоп среды в любом случае будут отличаться, а каждый раз перед публикацией в ручную запускать прод задачи для сборки — не вариант.
Вы, наверно, хотели сказать не bower, а grunt — потому что gulp и bower, насколько я знаю вещи разного плана — первый таск-менеджер, а второй менеджер пакетов.
Если будете рассматривать тему фронт-енда, то хотелось бы рассмотреть проблему привязки (binding) задач (grunt и gulp) к конфигурации (debug, release и т.д.) билда проекта — если это вообще на данном этапе решаемо. Надеюсь что можно как-то программно вызывать запуск задач — тогда настройку какие задачи запускать, можно делать в Stаrtup файле. Если же binding задач к событиям, вещь в себе и доступна только из контекстного меню Task Runner Explorer — то это конечно очень грустно — задачи для прод и девелоп среды в любом случае будут отличаться, а каждый раз перед публикацией в ручную запускать прод задачи для сборки — не вариант.
Но в рекомендациях к другим MVC Фреймворкам очень часто вижу обратный пункт «все должно быть в модели, метод контроллера должен быть прост и минимален».
Возможно, вся логика должна находиться в вспомогательных классах, методы которых и вызывает модель? Поправьте, если ошибся.
Sign up to leave a comment.
Готовим ASP.NET5, выпуск №2 – повторим азы для самых начинающих