Товаров: 0 (0р.)

История создания веб студии: Как я создавал WEB-студию: история одного стартапа

Содержание

Как я создавал WEB-студию: история одного стартапа

Расскажу о том, как я создал свою WEB-студию и какие из этого вынес уроки.

http://www.webkapriz.ru/nodesign/001/images/display.jpg» hspace=»4″ align=»left» vspace=»4″/>Сейчас полно «деловой литературы», но бизнес можно изучить только на практике. Особенно в России. Расскажу о том, как я создал свою маленькую веб-студию и какие из этого вынес уроки.

1. Подготовка

К сожалению, подготовиться к началу собственного бизнеса просто невозможно, нереально работать на оклад и постепенно создавать фирму. Но я наивно полагал, что, сделав сайт и запустив рекламу, я смогу просто сидеть на телефоне и ждать заказов. Я работал в одной из небольших, но стабильных компаний, а редкие заказы (шабашки) через знакомых собирал в портфолио на отдельном сайте. Через некоторое время я подумал, что готов к свободному полету, и уволился.

2.

Начало

Надо сказать, что уволился я не в самый удобный момент. Во-первых, у меня не было стартового капитала чтобы хоть прожить первое время — только зарплата (хотя и это не мало) и немного электронной наличности. Во-вторых, я должен был кормить не только себя, но ещё жену и сына, а в-третьих, в силу моральных качеств у меня не было «левых клиентов», т.е. я не увел с фирмы ни одного заказчика.

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

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

Через некоторое время, как и планировал, запустил рекламу и стал ждать звонков… Но их не было. После несколько дней ожидания мною завладело беспокойство, я распределил оставшиеся деньги на два месяца вперёд и усилил рекламу. Лишь за одно я был спокоен — на еду денег пока хватит.

3. Кризис

Реклама шла, а заказов почти не было, деньги кончались. К концу первого месяца я взял в долг у брата. Мое беспокойство превратилось в депрессивное расстройство, и на телефонные звонки отвечал только мой помощник — я мог только сидеть и смотреть телевизор, предварительно приняв успокоительное. Вечером засыпал хорошо, но утром невроз начинался снова —  не помню, сколько это длилось.

Я начал завидовать Саше (помощнику), что он холост и ему дают деньги родители, да еще и я отдаю процент с заказов. Радужные перспективы сменились слякотью сумрачных будней.

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

4. Пробуждение

Планируя организацию своей фирмы, я создал отличную базу для работы фрилансером.

Мы могли работать по низким ценам, могли быть всегда на связи и были лично заинтересованы в каждом заказе. Размещая объявления о поиске удаленной работы, мы нашли двух постоянных клиентов на администрирование сайтов, у нас появился небольшой, но стабильный доход.

Это, конечно, надо было сделать с самого начала (найти постоянных клиентов) но… «знать бы прикуп…».

И вот поступил крупный (для нас) заказ, благодаря которому мы «сделали план». Это было чудесно. В тот момент, когда у меня должны были закончиться финансы, появились новые, что очень обрадовало и депрессия начала проходить. А, может, просто принимал хорошее лекарство.

5. Работа

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

С третьего месяца лично я стал зарабатывать почти столько же, сколько получал в веб-студии менеджером. Но зато теперь я жил своей жизнью, только надо было брать мобилу с собой и стараться найти место потише для разговора с потенциальным клиентом (надо же создать впечатление, что я в офисе). Телефон мы используем «База офис» (http://gobaza.ru/) — когда звонков немного это наилучший вариант (по цене). Коротко говоря — это виртуальный телефон, перенаправляющий звонок на другой свободный номер (например мобильник) по списку. Очень удобно.

Смотрел ещё http://mangooffice.ru/, но только по цене «Базу» выбрал.

Естественно, мы работали неофициально, да и кто из фрилансеров платит налоги?

Одно меня раздражает:  при том, что вся страна работает «в серую», каждый желает иметь дело с юрлицом. Есть еще одна особенность: воспитанный в советском союзе человек редко спрашивает о скидках, о снижении цены и т.п. Только настоящий предприниматель выясняет все варианты и условия работы, коих в сфере веб-разработки «вагон и маленькая тележка».

6. Бизнес

С самого начала я вбил себе в голову одну вещь — бизнесмен не должен работать. Бизнесмен — это человек, который задает правила игры, результатом которой должно быть всеобщее благосостояние. Но, чтобы задавать правила, я должен был обладать уникальным преимуществом, например:

— бухгалтерия (юрлицо)

— технические средства (сервер и т.п.)

— знания и опыт

Из этого у меня были только знания и опыт. Мне не оставалось ничего другого как нанять неспециалиста.

У меня было преимущество: я учил его и мог платить маленькую зарплату. Брать неспециалистов — хороший ход, если есть работники, которые всему научат.

Основная цель владельца веб-студии, да и любого малого бизнеса, — чтобы работники были заинтересованы в большем количестве клиентов, а также не имели возможности переманивать этих клиентов.

Вот Студию Артемия Лебедева (http://www.artlebedev.ru) наврядли кто-то променяет на частного веб-мастера… А «Чейм!»?

Тут мне закралась мысль о создании бренда. Для этого мы создали несколько некоммерческих проектов (наиболее удачный — «Блогосферные нов.ости»).

Название «Chame Creative Group» заменили на  «Студия «Чейм!», поняв, что  люди не будут говорить «шаме». Обновили сайт.

В разделе услуги сделали рубрику «рекомендуем» и поместили ссылки на лучших веб-разработчиков. Если заказчик может заплатить несколько тысяч, то пусть лучше идет в Биплан, к примеру, и его затраты окупятся. Мы из себя авторитетов не строим, мы — прозрачная веб-студия.

Следующим шагом планирую запустить «вирусный» рекламный ролик с прикольной песенкой, но хочется сделать качественный «вирус», что пока не получается.

7. Уроки

— Чтобы стать независимым, надо менять психологию. Нужно уволиться не имея «богатого папеньки», который дает деньги.

— Чтобы стартовать, нужно заниматься только двумя вещами: экономить и зарабатывать. Если не можешь прекратить тратить — «свой бизнес» не для тебя.

— Чтобы не впасть в депрессию нельзя останавливаться ни на минуту. Слабость духа — первый враг.

Работайте со всеми заказчиками. Первое время надо наработать базу и статистику. Если сразу сказать: «мы делаем сайты от 1000 у.е.» —  вы можете просто не найти заказов.

Общайтесь с «братьями по разуму», с единомышленниками. Если все твердят, что действуешь неразумно, и поддержки нет совсем, будет очень сложно.

Но поддержка должна быть только моральной, не финансовой.

Почитайте записи сообщества «First Business» 1st_biz, посмотрите в десятый раз «Бойцовский клуб» — лично мне это помогало.

Источник: 1bizsouz’s Journal 

агентство, производство, конвейер, продукт / Блог компании Кельник / Хабр

По данным, любезно предоставленным аналитическим порталом CMS Magazine, «на радарах» видно 286 живых русскоязычных веб-студий размером 1—3 человека, 626 — размером 4—7 человек, и 556 — размером 8—15 человек. «Живые» — это те, кто опубликовал на портале хотя бы одну работу в 2012—2013 годах.

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

Последние годы рынок всё чаще говорит о необходимости позиционирования, маркетинга и PR для веб-студий, причём если раньше это относилось к Top-10 компаний, сегодня об этих чуждых интернет-специалистам материях приходится задумываться той самой тысяче с численностью сотрудников 4—15. К счастью, и на Хабре появляются хорошие статьи на эту тему. Мы хотим дать взгляд на проблему позиционирования ещё с одной стороны.

Позиционирование и процессы неразрывно связаны


Прописная маркетинговая истина: позиционирование — это не то, что вы говорите, а то, что думает о вас ваша целевая аудитория.

Поэтому всякое позиционирование должно подтверждаться практикой. Если вы говорите, что умеете делать высоконагруженные проекты, они не просто должны быть у вас в портфолио, у вас процесс должен быть под них заточен — от компетенций сотрудников до состава работ. Если вы говорите о суперкрутом клиентском сервисе, под него также должен быть заточен процесс — аккаунт-менеджмент, выявление скрытых ожиданий, обучение клиента и многое другое.

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

Технологии или клиентский сервис?


Есть два класса компетенций, которые дороговато прокачивать вместе — технологические компетенции (супер-адаптивно-кроссбраузерная вёрстка, высоконагруженные приложения, сложные сервисы и т.п.) и компетенции клиентского взаимодействия (хорошие договоры, мощный pre-sale, выявление и фиксация ожиданий, выявление скрытых сторон, влияющих на проект, креатив, и т.п.).

Условно говоря, один нормальный программист в небольшой веб-студии может расти либо в супер-программиста, либо в менеджера проекта, и это сложно делать одновременно.

То же касается и компании в целом — если компания полностью обеспечена загрузкой и вовремя получает оплату, ей выгоднее прокачивать либо технологические компетенции, либо клиентские.

До недавнего времени любая компания была вынуждена прокачивать и те, и те.

Уникальные проекты или сформированный продукт?


Для крупных компаний с прокачанным клиентским сервисом каждый проект уникален. Потому что у каждого клиента своё позиционирование, свои целевые аудитории, свои ключевые сообщения, услуги, продукты, своя структура бизнеса. Поэтому решение таких задач требует процессов, выстроенных под решение типовых задач («сделайте мне сайт»), но для уникальных клиентов.

Бывает другой вариант, когда компания устаёт делать уникальные продукты и создаёт сформированный продукт. Яркий пример — компании 1С-Битрикс и UMI.CMS, которые выросли из веб-студий, но перестали делать сайты для клиентов и начали продавать «коробки».

Некоторые компании начинают создавать и продавать SaaS-сервисы (например, QSoft и amo. CRM). Очевидно, что под разработку и продажу SaaS-сервиса нужна полностью иная оргструктура, нежели под кастомную клиентскую разработку.

И что теперь?


А теперь перемножим две этих оси и получим плоскость.

И разберёмся, что из этого что, начиная с наиболее привычной истории про агентства.

Агентство

По определению, агентство — это компания, которая является представителем заказчика. Агентства имеют высокие компетенции клиентского взаимодействия, и умеют переводить с языка «клиентской проблемы» на язык «конкретных решений». Уже конкретные задачи агентства размещают среди компаний-профессионалов, которые создают те или иные продукты.

Допустим, рекламное агентство придумывает креатив, подбирает рекламные каналы и механики вовлечения, после чего размещает заказы на производство видеороликов, сайтов, ведение групп в соцсетях и т.п. среди компаний, которые этим занимаются. Курируют результаты работ и анализируют общий выхлоп рекламной кампании. Сегодня на рынке чистых агентств почти нет, большинство из нас имеют внутри собственное производство, но ряд работ активно размещают и на субподряде.

Может показаться, что это лишнее звено между клиентом и конечными исполнителями, но это не так. Большинство клиентов агентств просто не смогут найти общий язык с большинством конечных исполнителей. Это касается, например, постановки задач, процессов работы, договоров, толерантности к финансовым разрывам.

Чтобы стать агентством, нужно на всех уровнях прокачивать компетенции клиентского взаимодействия, связанного с реализацией уникальных проектов:

  • Договоры,
  • Процессы (предпродажи, тендерные истории, коммерческие предложения, проектирование и итеративная разработка…),
  • Люди (нужны менеджеры с крутым опытом и коммуникативными навыками, а также крутые техлиды в команде, способные контролировать результат любого уровня сложности),
  • Финансовое планирование (работа с дебиторской задолженностью, «подушка безопасности», этапности оплат, сегментация клиентской базы…),
  • Субподрядчики (нужная наработанная база субподрядчиков по очень широкому спектру работ — от иллюстрации в стиле гравюр до тонкой настройки экзотических баз данных).

Заказное производство

Веб-студия, которая не становится агентством, но имеет желание заниматься уникальными проектами, способна вырасти в хорошее заказное производство (production-компанию).

В отличие от агентства, заказные производства работают либо с очень компетентными конечными клиентами (например, где есть собственный действительно мощный отдел интернет-маркетинга), либо с агентствами как субподрядчики.

В отличие от агентства, заказные производства могут и должны заранее фиксировать требования и брать доплату за отступление от них. Для агентств это просто невозможно, так как клиентские требования на старте большинства проектов отсутствуют или расплывчаты.

Заказное производство может быть очень чётко спозиционировано, и это будет очень оценено агентствами. «Мы делаем только соцсети на Python», «Мы — 20 программистов на 1С-Битрикс, способные решить любую задачу без ломки ядра», «Мы всегда сдаём вёрстку без багов», и так далее.

Чтобы стать заказным производством, нужно прокачивать процессы немного в другую сторону:

  • Договоры должны включать другие условия по изменениям требований и более жёсткие санкции за дедлайны,
  • Процессы больше выстраиваются на высокую производительность при равномерной загрузке, практически отсутствует пресэйл, вместо продаж — поиск партнёрских агентств и отработка взаимодействия, возможны более-менее гибкие методики производства,
  • Люди прокачиваются в мощных технических специалистов и техлидов,
  • Финансовое планирование подразумевает формирование равномерной загрузки засчёт работы с несколькими постоянными партнёрами…

Свой продукт

В том случае, если мучиться с каждым клиентом или снобским агентством-заказчиком надоело, хороший вариант — уйти в создание своего продукта. Так или иначе, многие компании проходили через этот этап, и либо перестали существовать как веб-студия, либо выделили появившиеся продукты в отдельные бизнесы.

Таким продуктом может быть «коробка», массовый онлайн-сервис, или что-то более экзотическое (профессиональная система для автоматизации ставок контекстной рекламы, например).

Проблема с уходом в свой продукт — в идее своего продукта и в финансовых возможностях некоторое время вкладывать в него ресурсы, не получая профита.

Практика показывает, что для появления идеи нужно основательно повариться где-то в верхней половине матрицы, чтобы окончательно осознать, какого продукта на рынке крайне не хватает, а вы при своих компетенциях реально способны создать. Если обратить внимание, видно, что интернет-компании создают продукты, базируясь на уникальном многолетнем каждой: уже упомянутые QSoft и amo.CRM, TRINET и eLama, RealWeb и «Гарпун», «Кельник» и Planoplan… Мы не брали идеи наобум, они вырастали из нашего опыта.

Конвейер

Конвейерное производство крайне недооценено и часто рассматривается другими компаниями рынка как «штамповка некачественной продукции» (подставьте синонимы по вкусу). На самом деле, конвейерное производство имеет большие перспективы для нижнего и среднего ценового сегмента.

«Конвейер» — это производство типовых продуктов с типовым качеством в типовые сроки (в отличие от агентств и производств, где продукт и сроки гарантированно уникальные). Из активно рассказывающих о себе в последний год к таким компаниям можно отнести смоленскую Web Canape и казанскую Reaspect.

Конвейер — это не продукт, потому что требует скорее бо́льших клиентских компетенций, нежели технологических. Особенно тут играет роль, что приходится общаться с менее компетентными клиентами, возможно, с первым опытом заказа сайта. Однако, последнее время у конвейеров появляется новая клиентура — компетентные клиенты, которые хотят сделать недорогой сайт для решения базовых задач. Например, чтобы протестировать бизнес-идею.

Quo vadis?


Сейчас лето, отличная пора для рефлексии. Подумайте, где вы находитесь сегодня, и куда вы хотите идти. Выбор сделать полезно, потому что он отсечёт всё лишнее.

Вы хотите стать производством? Перестаньте учиться «облизывать» некомпетентных клиентов. Ищите хорошие агентства.

Вы хотите стать агентством? Вкладывайтесь в обучение менеджеров и учитесь итеративно снижать проектную неопределённость. Планомерно снижайте внутренние объёмы производства.

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

Вы хотите делать конвейер? Перестаньте говорить о «молодом динамично развивающемся агентстве полного цикла» и просто делайте типовые недорогие сайты, чётко соблюдая сроки. Объясняйте клиентам, что вы не будете играться шрифтами, так как он купил типовой продукт.

Как я стал заниматься созданием сайтов

Приветствую вас, друзья! В этой статье поделюсь с вами историей о том, как я пришёл к тому, чтобы заниматься сайтами и открыть свою веб-студию. Скажу, что так было не всегда. Мой опыт в этой сфере деятельности начался с 2012 года. Прошло целых 4 года, многое изменилось. Но давайте обо всём по порядку.

Интерес к предпринимательской деятельности у меня пробудился в 2009 году, после окончания университета. Тогда я понял, что работа по найму – это не для меня, и я стал искать возможности открыть своё дело. Сперва это была точка по резке стекла и зеркал, затем – цех по производству мебели из стекла. Но вскоре мне стало понятно, что это не моё. А вот интерес к Интернету и компьютерам у меня был всегда.

Первый компьютер появился у меня в далёком 2004 году. О качественном Интернете в тот момент можно было только мечтать. Сначала он был медленным – настолько медленным, что пользоваться им было невозможно. Так продолжалось до появления высокоскоростного доступа. И вот тогда я стал более глубоко осваивать Интернет и всё, что с ним связано.

В 2011 году я завёл собственный блог на тему мобильных телефонов и за некоторое время довёл его до посещаемости в 2500 посетителей в сутки. Сейчас я им уже не занимаюсь. Но в процессе блоговедения было изучено много информации касательно создания сайтов, их продвижения и развития. Эта тема стала мне настолько интересной, что я решил специализироваться в этой области.

И вот тогда произошёл поворотный момент в моей жизни, когда я резко поменял род своих занятий. От производства я ушёл в тему создания сайтов.

Мой первый опыт заключался в том, что я искал клиентов, которые хотели себе простенькие сайты, и за чисто символическую плату (конкретные суммы называть не буду – они реально были незначительными) тренировался и набирал опыт. Постепенно мои проекты становились всё качественнее, а ценник медленно полз вверх.

Я считаю, что перед тем, как серьёзно заниматься каким-то бизнесом, нужно вникнуть в него самому. Самые успешные предприниматели – это те, которые полностью погружаются в своё дело, изучают его досконально, знают все нюансы. На любой вопрос они могут дать подробный ответ.

Некоторые думают так: «Зачем всё изучать? Можно же просто искать клиентов, а основную работу будут делать подрядчики». Такая точка зрения не приведёт ни к чему хорошему. Я смотрю на других предпринимателей и вижу, что всё получается только у тех, кто погружён в свой бизнес с головой.

Различные тренинги и курсы в Интернете, рассказывающие о том, что вы будете лежать на пляже, а в это время ваш бизнес будет работать и приносить вам деньги – это всё туфта. Эти тренинги не рассказывают о том, что для достижения такого результата придётся «пахать», причём не месяц и не два, а как минимум несколько лет.

Ну да ладно, это было небольшое отвлечение. Спустя некоторое время я пришёл к тому, что смог браться за более серьёзные проекты. И тогда у меня появился сайт, на котором вы сейчас находитесь. Сначала он выглядел по-другому – на нём был установлен платный шаблон. Но в прошлом году он значительно преобразился и обрёл свой фирменный дизайн.

Кстати, напишите в комментариях, что вы думаете об этом дизайне.

Вот так я пришёл к собственной веб-студии. Мне есть куда расти. Сейчас я активно занимаюсь развитием и продвижением своего сайта. Учитывая, что эта сфера очень конкурентная, приходится непросто. Но ведь главное – идти дальше. Вы согласны со мной?

С уважением, Сергей Чесноков

Перспективы развития веб-студии. План на 2020-2025 гг — CMS Magazine

Недавно я стал участником спора, в котором один из моих оппонентов сказал, что «веб-студии ждёт судьба фотосалонов, которые проявляли плёнки». Это меня немного зацепило и заставило задуматься. Как раз возле дома, где я живу, есть салон известной фотосети. Там по-прежнему торгуют фото-принадлежностями и можно заказать цифровую печать. Но теперь часть помещения занимает кафе, а по вечерам проходят занятия любителей вышивания.

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

В этой статье я делюсь своими мыслями о перспективах развития веб-студии.

Больше не нужно искать и обзванивать каждое диджитал-агентство
Создайте конкурс на workspace. ru – получите предложения от участников CMS Magazine по цене и срокам. Это бесплатно и займет 5 минут. В каталоге 15 617 диджитал-агентств, готовых вам помочь – выберите и сэкономьте до 30%.
Создать конкурс →

Риски веб-студий

Бизнес веб-студий — это клиентский бизнес. Многое в работе зависит от пожеланий клиента. А они зачастую бывают специфическими. Заказчик хочет получить сайт в соответствии со своими видением. И не всегда прислушивается к мнению профессионалов.

Интересное исследование провела компания McKinsey. Там, где компании обращают внимание на дизайн своих продуктов, в том числе веб-сайтов, растёт эффективность бизнеса. Для своих исследований McKinsey придумал MDI (McKinsey Design Index) — индекс, который отражает экономический эффект от дизайна. Вывод McKinsey — компании с высоким индексом MDI превзошли темпы роста конкурентов по отрасли в два раза.

McKinsey Design Index показывает соотношение дизайна и прибыли

В ряде случаев работа завершается некоторым недовольством и со стороны заказчика, и со стороны разработчика. Во многом из-за этого каждый менеджер пробует составить детальное ТЗ, чтобы заказчик не мог отвертеться от принятия работы. И всё равно ТЗ будет нарушено через 2-3 дня. Появляются новые идеи, задачи, пожелания от заказчика.

В попытках расти веб-студия чаще всего ориентируется на экстенсивный путь развития. Берёт больше заказов, делает больше сайтов. Соответственно, привлекает новых специалистов. То есть масштабирование идет от увеличения количества рабочей силы.

Но маленьким студиям, особенно в регионах, трудно конкурировать за хороших программистов, дизайнеров с крупными компаниями. Часто бывает так, что человек два года отработал, стал профессионалом и уходит в другую компанию или начинает работать удалённо на столичные заказы.

Часто веб-студии вместе с созданием сайта предлагают услуги SEO-оптимизации. Как правило, это входит в базовый набор. И есть ещё контекстная реклама. Но это уже дорого, и зачастую заказчики не выделяют на это бюджеты, достаточные для продвижения.

Вот так выглядит бизнес веб-студий в своей основе. Можно ли придумать что-то ещё?

Каким вы видите развитие веб-студии как индустрии в ближайшие годы?

Какой есть выход

Если студия умеет привлекать заказчиков для клиента, или продвигать холодильники в интернете, то почему бы ей самой их не продавать? Любые действия в сети сейчас можно детально измерить. Цифры подскажут, что выгодно, а что нет.

С точки зрения компании, если можно «вложить и заработать», то надо расширяться именно в эту сторону. Студии могут делать не только сайты, но и создавать свои цифровые продукты.

С помощью цифрового продукта можно расширить свой бизнес, привлекая меньшее количество ресурсов.

Что такое цифровой продукт

Цифровые продукты — это технологии, которыми пользуется сейчас каждый современный человек. Это сайты, приложения на смартфоне, облачные сервисы, электронные книги, кинофильмы, музыка, и так далее. Все эти цифровые продукты отвечают разным потребностям. Их основная задача — сделать жизнь потребителя проще, а также помочь ликвидировать «боль» клиента.

Пример цифрового продукта

  • 1C. Они сделали коробочку, стали везде продавать. На этом продукте живут франчайзи, у которых нету возможности развиваться кроме как через привлечение новых клиентов и персонала. Но, тем не менее, эти франчайзи создают свои плагины, дополнения к 1С, и пытаются их продавать.
  • Bitrix24, amoCRM — это примеры продуктов B2B. Но продукт может быть и приложением для смартфона, то есть В2С. То есть продукт — это любая коробочка.
  • Яндекс.такси закрывает «боль» клиента с поиском такси. Вызов идёт через приложение, без необходимости разговора с оператором, а также даёт возможность выбрать варианты тарифов, от эконома до премиум.
  • ITunes — позволяет слушать лицензионную музыку и фильмы высокого качества по ежемесячной подписке за символическую плату.
  • WhatsApp решает проблему обмена бесплатными сообщениями и медиафайлами.
  • Почтовые сервисы облегчают работу с письмами и позволяют отправлять какие-либо важные документы, файлы сидя за компьютером.

Быстрая проверка гипотезы

Одним из главных преимуществ цифрового продукта является быстрая проверка гипотезы. Мы в iAGE работаем по следующей схеме: создаем прототип и привлекаем трафик. Нам не нужно ждать год-два, мы получаем результат в течении нескольких недель, а иногда и дней.

При тестировании гипотез мы используем 5 основных каналов привлечения трафика:

  1. Продвижение через социальные сети. Привлечение трафика достигается за счет контента на страницах бренда в социальных сетях.

  2. Email-рассылки. Сегодня рассылки рассматриваются как один из эффективных и бюджетных видов трафика. При работе с ними важно составить грамотный план отправки писем, сделать интересный контент и собрать «живую» базу подписчиков. Преимущества — теплая ЦА, бюджетный вариант быстро донести до клиентов нужную информацию, больше возможностей в плане оформления. Недостатки — массовая рассылка (спам) вызывает неоднозначное отношение пользователей к email-маркетингу как к формату.

  3. Контекстная реклама. Особенность этого источника в том, что посетителям показывают релевантные их запросам объявления. Текстовые предложения транслируются в поиске над/под органической выдачей.

  4. Органический трафик. Этот канал приводит посетителей из естественной выдачи поисковиков по конкретным запросам. Соответственно сайт оптимизируется под тематику для вывода в ТОП-20, 10, 5, 3. Чем выше позиция, тем больше посетителей можно ожидать на ресурсе.

  5. Мессенджеры. Популярные приложения в России — WhatsApp, Skype, Telegram, Вайбер. Мессенджеры — это облегченный вариант социальных сетей для гаджетов. Плюсы — круглосуточная доступность, интерфейс под мобильные устройства, простая навигация.

Тестирование гипотез у нас поставлено на поток и мы готовы проконсультировать вас по всем аспектам создания цифрового продукта.

Цифровой продукт идеально сочетается с новой версией пирамиды Маслоу. Три высших потребности человека теперь выглядят так: родительство, поиск подходящего партнёра и сохранение отношений. Именно эти потребности и позволяют закрыть цифровые продукты. Мы можем меньше уделять время рутине и концентрироваться на том, что действительно важно — семья, саморазвитие, путешествия и т.д.

Как вы будете развивать свою студию?

Заключение

Рынок веб-разработки сужается с каждым годом. Крупных заказчиков больше не становится, к тому же часть из них переносит разработку in house. Малый бизнес использует конструкторы сайтов или сам делает небольшие проекты на готовых cms вроде всем известного WordPress. Основным заказчиком для региональных студий остаётся средний бизнес. Но и здесь видно, что средний чек падает.

Выход для веб-студий я вижу в создании цифровых продуктов. Если научиться их делать, то открываются поистине безграничные возможности. Но тут важно очень точно угадать потребности рынка. Ещё одна почта, соцсеть, мессенджер никому не нужны. Но остаются ещё сотни, а то и тысячи незакрытых потребностей. Их надо распознать и предложить решение.

Мы в iAGE готовы вас проконсультировать по всем аспектам цифрового продукта, начиная с тестирования до разработки. Звоните, всегда поможем.

история создания — Самая полная в Рунете энциклопедия интернет-маркетинга

Материал из Самая полная в Рунете энциклопедия интернет-маркетинга

Студии «А-квадрат» и «Артографика»

В 1992 году Артемий Лебедев, которому было 17 лет, основал студию дизайна «А-квадрат». В 1993 году он открыл новую студию «Артографика» (рис. 1).

Рис. 1. Студия «Артографика»

В студии был один сотрудник — сам Артемий Лебедев, который разрабатывал логотипы, фирменные стили и т. д. Для привлечения клиентов Лебедев создал портфолио работ для несуществующих компаний (рис. 2). На тот момент Артемий считал, что один человек способен сделать заказ от начала (идеи, концепции) и до конца (дизайнерского воплощения), и клиенту удобнее работать с конкретным дизайнером, который полностью отвечает за весь процесс. Одновременно (с 1993 по 1995 гг.) Лебедев работал в компании «Макцентр».

Рис. 2. Логотипы вымышленных компаний, придуманные Артемием Лебедевым

Студия «WebDesign»

В 1995 году Артемий Лебедев начал профессионально заниматься дизайном в интернете и создал студию «WebDesign» (рис. 3). Сначала он работал один, позже стал нанимать сотрудников, так как количество заказов увеличилось.

Рис. 3. Сайт студии «WebDesign»

В 1997 году годовой оборот его компании составлял более 50 тыс. долларов. Одновременно с веб-дизайном студия занималась графическим дизайном.

Примеры работ студии «WebDesign»:

Рис. 4. Пример работы студии «WebDesign» Рис. 5. Пример работы студии «WebDesign» Рис. 6. Пример работы студии «WebDesign»

Со временем у Артемия Лебедева и его команды менялся уровень работ и подход к клиентам студии.

В период существования «WebDesign» приходилось детально объяснять заказчикам, как долго делаются веб-страницы, чем «WebDesign» отличается от других студий и откуда появляется та или иная цена на услуги. Девиз Лебедева «Долго. Дорого. Охуенно» возник не сразу.

Стоимость услуг студии «WebDesign»

Ценовая политика была открытой: стоимость «небольшого сайта» — около 4—10 тысяч долларов, более крупного — свыше 10 тысяч долларов. Для сравнения: в 90-х годах квартира в Киеве стоила около 13—15 тысяч долларов, в Москве немного дороже.

Процесс создания сайтов в 90-х годах в России был проще, чем в 2000-х. Дизайн, в основном, сводился к подбору фона страниц (HTML-страниц, как правило, было не больше 30), созданию нескольких иллюстраций и таблиц. Вся работа, по словам Лебедева, занимала от 2 до 30 дней.

Профессиональных разработчиков сайтов в России в период до 1998 года было немного, и студия «WebDesign» заняла лидирующие позиции на рынке.

«Студия Артемия Лебедева»

С июня 1998 года компания «WebDesign» стала называться «Студия Артемия Лебедева». Со временем имя Лебедева превратилось в бренд.

Рис. 7. Цитата Артемия Лебедева о принципах «Студии»

К лету 1998 года студия «WebDesign» создала проекты для компаний «Яндекс», московского представительства «General Motors». Гран-при на конкурсе «Лучшие WWW-страницы России» получили сайты, которые Лебедев создал для компаний «Vessolink», «Comstar Telecommunications», «Mobile TeleCom».

18 июня 1998 года на сайте [www.design.ru www.design.ru] появилось сообщение, что «»WebDesign» меняет название на имя. Теперь это Студия Артемия Лебедева». На первый план вместо абстрактного названия студии вышло имя её создателя, что добавило компании индивидуальности.

1998 — 2015 годы

Рис. 8. Портрет команды «Студии Артемия Лебедева» в 1998 году

В 1998 году команда состояла из 12 человек: 2 дизайнера (включая Лебедева), 2 программиста, 2 менеджера, 3 верстальщика, 2 рецензента, 1 «главный по культурным проектам» (рис. 8).

Изменилась ценовая политика компании. До 1998 года стоимость проекта зависела от размера сайта (в килобайтах). В 1998 году на сайте компании было заявлено, что Студия не измеряет заказы в килобайтах, а продаёт идею, стоимость которой не зависит от количества и размера страниц проекта, площади графики и т.д.

* 2000—2002

К 2000 году число сотрудников компании возросло до 22 человек. До 2003 года информация обо всех проектах и сотрудниках была открытой. На сайте Студии появлялись новости о рабочей жизни членов команды Лебедева, например, что один из дизайнеров повысил квалификацию, а другой снова начал курить и т.д.

В 2000 году в Студии были созданы сайты для компаний «Alcatel», «Hewlet-Packard», «Audi», писателя Бориса Акунина. Проводились семинары и учебные курсы для обмена опытом с коллегами.

В 2001 году возникло новое направление деятельности Студии — промышленный дизайн.

Одни из самых известных в этой области работ:

1) Дизайн клавиатур с кнопками, в которые встроены миниатюрные дисплеи.

На дисплеях отображается, чем в данный момент управляет клавиша. Клавиатуры получили название «Оптимус максимус» и «Оптимус мини три» и в 2008 году удостоились первой премии на международной выставке «iF communication». Впоследствии были созданы другие модели клавиатур.

2) Дизайн микроволновой печи «Samsung» (рис. 9).

Рис. 9. Дизайн микроволновой печи Samsung

В 2001 году в Студии насчитывалось более 40 человек, в 2002 году — 64 сотрудника.

* 2005

Команда Артемия Лебедева в 2005 году — более 100 человек (рис. 10):

Рис. 10. Команда «Студии Артемия Лебедева», 2005 год

В 2005 году в Студии было 4 арт-директора, должность Артемия Лебедева называлась «художественный руководитель».

* 2011

К 2011 году компания насчитывала 10 направлений деятельности:

  • Графический дизайн
  • Промышленный дизайн
  • Презентации и видео

Команда Студии в 2011 году (рис. 11):

Рис. 11. Команда «Студии Артемия Лебедева», 2011 год

* 2014—2015

В 2014 году — в Студии 351 человек, включая сотрудников московского, киевского и нью-йоркского офисов (рис. 12, 13, 14).

Рис. 12. Команда «Студии Артемия Лебедева», московский офис, 2014 год Рис. 13. Команда «Студии Артемия Лебедева», киевский офис, 2014 год Рис. 14. Команда «Студии Артемия Лебедева», нью-йоркский офис, 2014 год

В январе 2015 года на сайте компании было объявлено, что «В 2015 году Студия Артемия Лебедева сделает невозможное».

К середине декабря 2015 года Студия насчитывала 3093 работы, среди которых проекты для крупных компаний (например, для «Газпрома»), ресторанов, театров, кинотеатров и т.д.

Читайте другие статьи на тему «Студия Артемия Лебедева»


Полезные ссылки

Веб-студия АВАНЗЕТ | История развития и успеха

О компании: История развития и успеха веб-студии АВАНЗЕТ. Работаем со всеми регионами России, представительства компании находятся в Москве (Зеленоград) и Краснодаре.   Наш сайт a1z.ru, телефон для бесплатной консультации +7 (903) 455-3830. 

Веб студия АВАНЗЕТ предоставляет услуги по дизайну, созданию сайтов и комплексному продвижению в сети интернет с 2011 года. Мы постоянно повышаем свой профессиональный уровень в веб-разработке, изучаем новые тенденции и совершенствуемся для того, чтобы максимально качественно удовлетворять потребнеости наших клиентов.

НАША МИССИЯ – помогать профессионалам своего дела достигать вершин в бизнесе.

НАШЕ КРЕДО – мелочей нет – высочайшее качество во всех деталях.

История развития и успеха веб-студии АВАНЗЕТ

  • Созданием бизнес сайтов в г. Новороссийске мы занимаемся с апреля 2011 года. До этого периода — основным направлением деятельности веб-студии была монетизация сайтов. 
  • Начав работать в Новороссийске, и создавая сайты для наших клиентов, веб-студия брала любые заказы и стремилась выполнить их так, как просил клиент. Часто результат получался весьма посредственным.
  • Набравшись опыта и желая работать более качественно, мы стали предлагать нашим клиентам такие варианты, которые соответствуют современным тенденциям. Иногда удавалось убедить заказчика и тогда получалось – хорошо!
  • Мы стремимся достичь лучших результатов, поэтому подход поставить себя на место клиента и думать за него так, как будто это наш собственный бизнес — самый эффективный. Если заказчик нам доверял – получалось отлично!
  • Сейчас мы стремимся стать лучшими в своей профессиональной области, чтобы оказывать услуги нашим клиентам максимально качественно. Подход к разработке сайтов в комплексе с продвижением — дает наилучший результат.
  • SEO оптимизация на этапе разработки дает быстрое естественное продвижение в поисковой выдаче. Наши сайты быстро индексируются и их «любят» поисковые системы.
  • Главная наша цель — повышать эффективность бизнеса наших клиентов, поэтому мы никогда не забываем про маркетинговую составляющую при разработке сайта.

Почему нам доверяют наши клиенты?

  • Три четверти клиентов, которые обращаются к нам за услугой разработки сайта, заключают долгосрочные договора на обслуживание и продвижение, потому что результат, который они получают, часто превосходит их ожидания.
  • Получая услуги веб-студии высокого профессионального уровня, наши клиенты всегда чувствуют поддержку и опору в любой области, связанной с созданием, продвижением или рекламой сайтов.
  • Более половины заказчиков приходят к нам по рекомендации наших довольных клиентов. Смотрите ОТЗЫВЫ О ВЕБ-СТУДИИ. Ваши цели и задачи становятся нашими общими на все время сотрудничества.

Веб-студия АВАНЗЕТ это:

  • Творческая креативная команда профессионалов: дизайнеров, программистов, копирайтеров, маркетологов
  • Свыше 150 успешно выполненных интернет-проектов;
  • Более 30 прибыльных сайтов в доверительном управлении;
  • 150 зарегистрированных доменов в национальной и международных зонах;
  • Надежный, недорогой, облачный хостинг

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

Работая над каждым проектом, мы стремимся воплотить идею заказчика стильно, лаконично и информативно. Главный критерий работы веб-студии АВАНЗЕТ- это качественное исполнение проектов, поэтому наш лозунг звучит так:

Мы создаем сайты, которые работают на Ваш бизнес!

Наши конкурентные преимущества:

  • ГАРАНТИРОВАННЫЙ РЕЗУЛЬТАТ. Заказывая сайт, Вы получаете готовый веб-сайт с современным дизайном, наполненный SEO оптимизированными текстами, установленными счетчиками статистики, корпоративной почтой, удобной системой управления сайтом (CMS), недорогой надежный хостинг с резервным копированием и антивирусной защитой.
  • СПРАВЕДЛИВАЯ СТОИМОСТЬ УСЛУГ. Стоимость сайта рассчитывается по Прейскуранту, получить расчет предварительно Вы можете отправив нам заявку. Мы гарантируем высокое качество услуг по справедливым ценам, прозрачное ценообразование и отсутствие скрытых платежей.
  • ВЫСОКИЙ УРОВЕНЬ ОБСЛУЖИВАНИЯ. Если вы решили заказать сайт в нашей веб-студии, то Вы получите персонального менеджера, который всегда будет держать вас в курсе работ по проекту, информировать о ходе разработки и представлять подробные отчеты на каждом этапе создания сайта.

Почему с нами выгодно и удобно работать?

  • ПРОФЕССИОНАЛИЗМ В РЕШЕНИИ ВСЕХ ВОПРОСОВ. Мы профессиональная студия создания сайтов и предлагаем нашим клиентам наилучшие решения на всех этапах разработки сайта, информационной и технической поддержки веб-сайта, а также в процессе продвижения и проведении рекламных кампаний в сети Интернет.
  • КОМПЛЕКСНОЕ ОБСЛУЖИВАНИЕ САЙТА. Все услуги веб-студии: веб-дизайн, программирование, верстка и подготовка текстов выполняются в комплексе, с высоким качеством и в сжатые сроки.
  • ОРИЕНТАЦИЯ НА ПОТРЕБНОСТИ КЛИЕНТА. Параллельно с процессом создания сайта, мы по желанию клиента проводим маркетинговые исследования, направленные на определение целевой аудитории клиента и наилучших способах взаимодействия с ней.

В своей работе мы стремимся помочь нашим клиентам в создании эффективных инструментов для развития бизнеса и увеличения продаж. Для нас очень важно, то, что наши клиенты со временем становятся постоянными партнерами, поэтому приоритетом является качество обслуживания клиентов, а не их количество.

Наша главная цель – помочь разобраться во всех деталях и выработать максимально эффективное решение Ваших задач. Ваш успех – наша гордость!

Начало работы в Интернете — Изучение веб-разработки

Начало работы в сети — это краткая серия статей, знакомящих вас с практическими аспектами веб-разработки. Вы настроите инструменты, необходимые для создания простой веб-страницы и опубликуйте собственный простой код.

История вашего первого сайта

Создание профессионального веб-сайта — это большая работа, поэтому, если вы новичок в веб-разработке, мы рекомендуем вам начать с малого. Вы не создадите еще один Facebook сразу, но создать собственный простой веб-сайт в Интернете несложно, поэтому мы начнем с него.

Проработав статьи, перечисленные ниже, вы с нуля выйдете на свою первую веб-страницу в Интернете. Начнем наше путешествие!

Установка базового ПО

Когда дело доходит до инструментов для создания веб-сайта, есть из чего выбрать. Если вы только начинаете, вы можете быть сбиты с толку множеством редакторов кода, фреймворков и инструментов тестирования. В разделе «Установка основного программного обеспечения» мы покажем вам шаг за шагом, как установить программное обеспечение, необходимое для начала базовой веб-разработки.

Как будет выглядеть ваш сайт?

Прежде чем вы начнете писать код для своего веб-сайта, вы должны сначала спланировать его. Какую информацию вы демонстрируете? Какие шрифты и цвета вы используете? Как будет выглядеть ваш сайт? Мы описываем простой метод, которым вы можете следовать, чтобы спланировать содержание и дизайн вашего сайта.

Работа с файлами

Веб-сайт состоит из множества файлов: текстового содержимого, кода, таблиц стилей, мультимедийного содержимого и так далее. Когда вы создаете веб-сайт, вам необходимо собрать эти файлы в разумную структуру и убедиться, что они могут взаимодействовать друг с другом.Работа с файлами объясняет, как создать разумную файловую структуру для вашего веб-сайта и о каких проблемах вам следует знать.

Основы HTML

Язык гипертекстовой разметки (HTML) — это код, который вы используете для структурирования своего веб-контента и придания ему смысла и цели. Например, мой контент — это набор абзацев или список пунктов? Есть ли на моей странице изображения? У меня есть таблица данных? Основы HTML предоставляют достаточно информации, чтобы познакомить вас с HTML.

Основы CSS

Cascading Stylesheets (CSS) — это код, который вы используете для стилизации своего веб-сайта. Например, вы хотите, чтобы текст был черным или красным? Где на экране должен отображаться контент? Какие фоновые изображения и цвета следует использовать для украшения вашего сайта? Основы CSS познакомят вас с тем, что вам нужно для начала работы.

Основы JavaScript

JavaScript — это язык программирования, который вы используете для добавления интерактивных функций на свой сайт. Некоторыми примерами могут быть игры, вещи, которые происходят при нажатии кнопок или вводе данных в формы, эффекты динамического стиля, анимация и многое другое.Основы JavaScript дают вам представление о возможностях этого захватывающего языка и о том, как начать работу.

Публикация вашего сайта

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

Как работает Интернет

Когда вы заходите на свой любимый веб-сайт, в фоновом режиме происходит множество сложных вещей, о которых вы можете не знать.Принцип работы сети описывает, что происходит, когда вы просматриваете веб-страницу на своем компьютере.

См. Также

  • Web Demystified: отличная серия видеороликов, объясняющих основы Интернета, предназначенных для начинающих веб-разработчиков. Создано Жереми Патонье.
  • Веб-стандарты и веб-стандарты: в этой статье представлены некоторые полезные сведения об Интернете — как это произошло, что такое стандартные веб-технологии, как они работают вместе, почему «веб-разработчик» — это отличная карьера для выбора и какие виды лучших практики, о которых вы узнаете в ходе курса.

History API — Веб-технологии для разработчиков

Объект DOM Window обеспечивает доступ к истории сеансов браузера (не путать с историей WebExtensions) через объект history . Он предоставляет полезные методы и свойства, которые позволяют перемещаться вперед и назад по истории пользователя и управлять содержимым стека истории.

Понятия и использование

Перемещение вперед и назад по истории пользователя выполняется с помощью методов назад () , вперед () и go () .

Движение вперед и назад

Для перехода назад по истории:

 window.history.back ()
 

Действует так же, как если бы пользователь нажал кнопку Назад на панели инструментов своего браузера.

Точно так же вы можете двигаться вперед (как если бы пользователь нажал кнопку Вперед ), например:

 window.history.forward ()
 

Переход к определенной точке истории

Вы можете использовать метод go () для загрузки определенной страницы из истории сеанса, идентифицированной по ее относительному положению относительно текущей страницы.(Относительное положение текущей страницы: 0 .)

Чтобы вернуться на одну страницу назад (эквивалент вызова назад () ):

 window.history.go (-1)
 

Для перехода на страницу вперед, как при вызове forward () :

 window.history.go (1)
 

Аналогично, вы можете перейти на 2 страницы вперед, передав 2 и так далее.

Другой способ использования метода go () — обновить текущую страницу, передав 0 или вызвав его без аргумента:

 // Следующие утверждения
// оба имеют эффект
// обновляем страницу
окно.history.go (0)
window.history.go ()
 

Вы можете определить количество страниц в стеке истории, посмотрев на значение свойства length :

 пусть numberOfEntries = window.history.length
 

Интерфейсы

История
Позволяет управлять историей сеанса браузера (то есть посещенными страницами во вкладке или фрейме, в которые загружена текущая страница).

Примеры

В следующем примере слушатель назначается свойству onpopstate .А затем демонстрирует некоторые методы объекта истории для добавления, замены и перемещения в истории браузера для текущей вкладки.

 window.onpopstate = function (event) {
  предупреждение (`местоположение: $ {document.location}, состояние: $ {JSON.stringify (event.state)}`)
}

history.pushState ({page: 1}, "title 1", "? page = 1")
history.pushState ({page: 2}, "title 2", "? page = 2")
history.replaceState ({page: 3}, "title 3", "? page = 3")
history.back () // предупреждает "location: http://example.com/example.html?page=1, state: {" page ": 1}"
история.back () // предупреждает "location: http://example.com/example.html, state: null"
history.go (2) // предупреждения "location: http://example.com/example.html?page=3, state: {" page ": 3}" 

Технические характеристики

Совместимость с браузером

Обновите данные совместимости на GitHub Chrome Chrome для Android 9016 Chrome Chrome 9016 Android 9016
Desktop Mobile
Chrome Edge Firefox Internet Explorer Opera Safari16 Android Opera для Android Safari на iOS Samsung Internet
История Chrome Полная поддержка 1 край Полная поддержка 12 Firefox Полная поддержка 1 IE Полная поддержка 10 Опера Полная поддержка 3 Safari Полная поддержка 1 WebView Android Полная поддержка 1 Chrome Android Полная поддержка 18 Firefox Android Полная поддержка 4 Opera Android Полная поддержка 10.1 Safari iOS Полная поддержка 1 Samsung Internet Android Полная поддержка 1.0
задний Хром Полная поддержка Да Кромка Полная поддержка 12 Firefox Полная поддержка Есть IE Полная поддержка 10 Опера Полная поддержка Есть Safari Полная поддержка Да WebView Android Полная поддержка Да Chrome Android Полная поддержка Да Firefox Android Полная поддержка Есть Opera Android Полная поддержка Да Safari iOS Полная поддержка Есть Samsung Internet Android Полная поддержка Да
вперед Хром Полная поддержка Да Кромка Полная поддержка 12 Firefox Полная поддержка Есть IE Полная поддержка 10 Опера Полная поддержка Есть Safari Полная поддержка Да WebView Android Полная поддержка Да Chrome Android Полная поддержка Да Firefox Android Полная поддержка Есть Opera Android Полная поддержка Да Safari iOS Полная поддержка Есть Samsung Internet Android Полная поддержка Да
идти Хром Полная поддержка Да Кромка Полная поддержка 12 Firefox Полная поддержка Есть IE Полная поддержка 10 Опера Полная поддержка Есть Safari Полная поддержка Да WebView Android Полная поддержка Да Chrome Android Полная поддержка Да Firefox Android Полная поддержка Есть Opera Android Полная поддержка Да Safari iOS Полная поддержка Есть Samsung Internet Android Полная поддержка Да
длина Хром Полная поддержка Да Кромка Полная поддержка 12 Firefox Полная поддержка Есть IE Полная поддержка 10 Опера Полная поддержка Есть Safari Полная поддержка Да WebView Android Полная поддержка Да Chrome Android Полная поддержка Да Firefox Android Полная поддержка Есть Opera Android Полная поддержка Да Safari iOS Полная поддержка Есть Samsung Internet Android Полная поддержка Да
pushState Хром Полная поддержка 5 Кромка Полная поддержка 12 Firefox Полная поддержка 4
Полная поддержка 4
Примечания До Firefox 5 переданный объект сериализуется с использованием JSON.Начиная с Firefox 6, объект сериализуется с использованием алгоритма структурированного клонирования. Это позволяет безопасно перемещать более широкий спектр объектов.
IE Полная поддержка 10 Опера Полная поддержка 11,5 Safari Полная поддержка 5 WebView Android Полная поддержка ≤37 Chrome Android Полная поддержка 18 Firefox Android Полная поддержка 4
Полная поддержка 4
Примечания До Firefox 5 переданный объект сериализуется с использованием JSON.Начиная с Firefox 6, объект сериализуется с использованием алгоритма структурированного клонирования. Это позволяет безопасно перемещать более широкий спектр объектов.
Opera Android Полная поддержка 11,5 Safari iOS Полная поддержка 4.3 Samsung Internet Android Полная поддержка 1.0
replaceState Chrome Полная поддержка 5 Кромка Полная поддержка 12 Firefox Полная поддержка 4
Полная поддержка 4
Примечания До Firefox 5 переданный объект сериализуется с использованием JSON.Начиная с Firefox 6, объект сериализуется с использованием алгоритма структурированного клонирования. Это позволяет безопасно перемещать более широкий спектр объектов.
IE Полная поддержка 10 Опера Полная поддержка 11,5 Safari Полная поддержка 5 WebView Android Полная поддержка ≤37 Chrome Android Полная поддержка 18 Firefox Android Полная поддержка 4
Полная поддержка 4
Примечания До Firefox 5 переданный объект сериализуется с использованием JSON.Начиная с Firefox 6, объект сериализуется с использованием алгоритма структурированного клонирования. Это позволяет безопасно перемещать более широкий спектр объектов.
Opera Android Полная поддержка 11,5 Safari iOS Полная поддержка 4.3 Samsung Internet Android Полная поддержка 1.0
свиток Восстановление Хром Полная поддержка 46 Кромка Полная поддержка 79 Firefox Полная поддержка 46 IE Никакой поддержки Opera Полная поддержка 33 Safari Полная поддержка Да WebView Android Никакой поддержки Chrome Android Полная поддержка 46 Firefox Android Полная поддержка Есть Opera Android Полная поддержка Да Safari iOS Полная поддержка Есть Samsung Internet Android Полная поддержка 5.0
состояние Хром Полная поддержка Да Кромка Полная поддержка 12 Firefox Полная поддержка Есть IE Полная поддержка 10 Опера Полная поддержка Есть Safari Полная поддержка Да WebView Android Полная поддержка Да Chrome Android Полная поддержка Да Firefox Android Полная поддержка Есть Opera Android Полная поддержка Да Safari iOS Полная поддержка Есть Samsung Internet Android Полная поддержка Да

Легенда

Полная поддержка
Полная поддержка
Никакой поддержки
Нет поддержки
См. Примечания по реализации.
См. Примечания по реализации.

См. Также

Список литературы

Направляющие

History.pushState () — Веб-технология для разработчиков

В документе HTML метод history.pushState () добавляет запись в стек истории сеанса браузера.

Синтаксис

 history.pushState ( состояние ,  заголовок  [,  url ]) 

Параметры

состояние
Объект состояния — это объект JavaScript, связанный с новой записью в истории, созданной функцией pushState () .Всякий раз, когда пользователь переходит к новому состоянию , запускается событие popstate , а свойство state события содержит копию объекта состояния записи истории.
Объект состояния может быть чем угодно, что может быть сериализовано. Поскольку Firefox сохраняет объекты состояния на диск пользователя, чтобы их можно было восстановить после перезапуска пользователем браузера, мы накладываем ограничение на размер в 640 тыс. Символов для сериализованного представления объекта состояния .Если вы передадите объект состояния , сериализованное представление которого больше этого значения, в pushState () , метод вызовет исключение. Если вам нужно больше места, рекомендуется использовать sessionStorage и / или localStorage .
название
Большинство браузеров в настоящее время игнорируют этот параметр, хотя могут использовать его в будущем. Передача здесь пустой строки должна быть защищена от будущих изменений метода.Как вариант, вы можете передать краткое название состояния, в которое вы переходите. Если вам нужно изменить заголовок, вы можете использовать document.title .
url Дополнительно
Этим параметром задается URL новой записи в истории. Обратите внимание, что браузер не будет пытаться загрузить этот URL-адрес после вызова pushState () , но он может попытаться загрузить URL-адрес позже, например, после того, как пользователь перезапустит браузер. Новый URL-адрес не обязательно должен быть абсолютным; если он относительный, он разрешается относительно текущего URL.Новый URL-адрес должен иметь то же происхождение, что и текущий URL-адрес; в противном случае pushState () вызовет исключение. Если этот параметр не указан, устанавливается текущий URL-адрес документа.

Описание

В некотором смысле вызов pushState () аналогичен установке window.location = "#foo" в том смысле, что оба они также создают и активируют другую запись истории, связанную с текущим документом. Но pushState () имеет несколько преимуществ:

  • Новый URL-адрес может быть любым URL-адресом из того же источника, что и текущий URL-адрес.Напротив, установка window.location удерживает вас в том же документе, только если вы изменяете только хэш.
  • Вам не нужно менять URL-адрес, если вы этого не хотите. Напротив, установка window.location = "#foo"; создает новую запись в истории, только если текущий хэш не #foo .
  • Вы можете связать произвольные данные с новой записью в истории. При подходе на основе хешей вам необходимо закодировать все соответствующие данные в короткую строку.

Обратите внимание, что pushState () никогда не вызывает событие hashchange , даже если новый URL-адрес отличается от старого URL-адреса только своим хешем.

Примеры

Это создает новую запись в истории браузера, устанавливающую состояние , заголовок и url .

JavaScript

 const state = {'page_id': 1, 'user_id': 5}
const title = ''
const url = 'hello-world.html'

history.pushState (состояние, заголовок, URL) 

Технические характеристики

Совместимость с браузером

Обновите данные о совместимости на GitHub Chrome Chrome 9016 Android Chrome
Desktop Mobile
Chrome Edge Firefox Internet Explorer Opera Safari16 Android Opera для Android Safari на iOS Samsung Internet
pushState Chrome Полная поддержка 5 Кромка Полная поддержка 12 Firefox Полная поддержка 4
Полная поддержка 4
Примечания До Firefox 5 переданный объект сериализуется с использованием JSON.Начиная с Firefox 6, объект сериализуется с использованием алгоритма структурированного клонирования. Это позволяет безопасно перемещать более широкий спектр объектов.
IE Полная поддержка 10 Опера Полная поддержка 11,5 Safari Полная поддержка 5 WebView Android Полная поддержка ≤37 Chrome Android Полная поддержка 18 Firefox Android Полная поддержка 4
Полная поддержка 4
Примечания До Firefox 5 переданный объект сериализуется с использованием JSON.Начиная с Firefox 6, объект сериализуется с использованием алгоритма структурированного клонирования. Это позволяет безопасно перемещать более широкий спектр объектов.
Opera Android Полная поддержка 11,5 Safari iOS Полная поддержка 4.3 Samsung Internet Android Полная поддержка 1.0
Используется ли аргумент заголовка Chrome Никакой поддержки Нет Кромка Никакой поддержки Firefox Никакой поддержки IE Никакой поддержки Opera Никакой поддержки Safari Полная поддержка Да WebView Android Никакой поддержки Chrome Android Никакой поддержки Firefox Android Никакой поддержки Opera Android Никакой поддержки Safari iOS ? Samsung Internet Android Никакой поддержки

Условные обозначения

Полная поддержка
Полная поддержка
Никакой поддержки
Нет поддержки
Совместимость неизвестна
Совместимость неизвестна
См. Примечания по реализации.
См. Примечания по реализации.

См. Также

Visual Studio 2019 RC: начало работы с ASP.NET Core (часть 2) - статьи TechNet - США (английский)

В нашей предыдущей статье мы видели, как загрузить и установить Visual Studio 2019. RC, а также объяснил, как начать работу с Visual Studio 2019 RC. В этой части мы более подробно рассмотрим, какие шаблоны проектов доступны, и узнаем больше о новых возможностях Visual Studio 2019.Мы также увидим, как работать с ASP.NET Core. Управление представлением модели с помощью простого входа в систему с помощью SQL Server.

Надеюсь, вы все установили версию Visual Studio 2019 RC или, если текущий месяц пересечен, 2 апреля 2019 года вы, возможно, обновили или установили Visual Studio 2019. Если нет, прочитайте нашу предыдущую статью, в которой подробно объяснялось, как загрузить а также установите Visual Studio 2019 на свой компьютер.
В этой статье мы начнем с создания нашего нового проекта в Visual Studio 2019.
Чтобы запустить Visual Studio 2019, нажмите Windows Пуск и выполните поиск Visual Studio 2019.Вы можете увидеть Visual Studio 2019 RC или Visual Studio 2019, щелкните по нему.


Вы можете видеть, что Visual Studio 2019 RC будет открыт, как на изображении ниже, вы можете увидеть слева, как будет отображаться список недавно открытых проектов. Чтобы создать новый проект, нажимаем на создать новый проект.

Мы видим список установленных проектов для работы с Visual Studio 2019.

Здесь новое окно проекта имеет новый дизайн, чем наша предыдущая Visual Studio 2017.

Список языков на вершине

Мы видим новое поле со списком языков в верхней центральной части окна «Новый проект».

Мы видим, что в поле со списком языков есть параметры, указанные ниже:

  • Все языки
  • C ++
  • C #
  • Java
  • F # ​​
  • JavaScript
  • Python
  • Язык запросов
  • TypeScript
  • Visual Basic

По умолчанию выбраны все языки, и если пользователь выбирает C # , будут отображены все шаблоны проектов, относящиеся к C #, и пользователи смогут выбрать тип своего проекта и начать развиваться.Здесь, когда мы выбираем C #, мы видим, что для параметра Filter by было установлено значение C #, и был загружен список проектов, связанных с C #.

В наших предыдущих версиях, таких как Visual Studio 2017, все проекты будут загружаться под языком в виде дерева с левой стороны, как на изображениях ниже.
На изображении ниже показано окно создания нового проекта в VS 2017. Для различий между 2017 и 2019 годами я добавил изображение ниже:

Платформа Combobox

Мы видим, что в Visual Studio 2019 добавлена ​​новая функция под названием Выбор платформы.Мы можем фильтровать доступные проекты по платформе, если мы выберем Android в качестве платформы, мы сможем увидеть весь список доступных проектов для работы с приложением Android, используя Visual Studio 2019.

Тип проекта Combobox

Мы видим новую функцию, поскольку в Visual Studio 2019 добавлен выбор типа проекта. Мы можем фильтровать доступные проекты по типу проекта. Если мы выберем Android в качестве платформы, мы сможем увидеть весь список доступных проектов для работы с приложением Android, используя Visual Studio 2019.

Сначала мы начинаем работать с созданием веб-приложений в Visual Studio 2019.
Здесь мы выбрали язык как C #, платформу как Windows и тип проекта как Web из верхнего выбора, вы можете увидеть в разделе Фильтрация по: C #, Windows, Web на изображении ниже.

Мы можем увидеть веб-приложение ASP.NET Core с Windows в качестве поддерживаемой платформы, Linux и Mac OS для создания приложений MVC, Web API и SPA. И еще один веб-проект, который использовался для создания ASP.NET для .NET Framework, мы также можем создать другой тестовый проект NUnit для .NET Core.

Работа с веб-приложением

Здесь мы увидим, как работать с веб-приложением ASP.NET Core в Visual Studio 2019.

В шаблоне проекта мы выбираем веб-приложение ASP.NET Core и нажимаем «Далее».


Здесь мы выбираем путь к расположению нашего решения проекта и нажимаем «Создать», чтобы создать новый проект ASP.NET Core.

На следующей странице мы можем выбрать наш.NET Core, также мы можем увидеть список доступных шаблонов проектов для ASP.NET Core как:

  • Пустой : для создания пустого шаблона для приложения ASP.NET Core
  • API : для работы с веб-API ASP.NET Core.
  • Веб-приложение : для создания веб-приложения ASP.NET Core с помощью страниц Razor
  • Веб-приложение (Модель-Представление-Контроллер) : Для работы с ASP.NET Core MVC View Controller и WEB API
  • Библиотека классов Razor : для работы с библиотекой классов Razor
  • Angular : для создания веб-приложения с использованием ASP.NET Core и Angular
  • React.js : для создания веб-приложения с использованием ASP.NET Core и React.js
  • React.js и Redux : для создания веб-приложения с использованием ASP.NET Core, React.js и Redux

Кроме того, если нам нужен дополнительный шаблон проекта для работы с ASP.NET Core, мы также можем установить его по ссылке ниже, щелкнув ссылку « Получить дополнительные проекты ». Когда мы нажимаем на ссылку, мы видим, что открыта новая веб-страница и отобразить все доступные шаблоны для Dotnet.

В нашей следующей статье мы подробно рассмотрим установку и работу с ASP.NET Core Blazor с использованием .NET Core 3.0 в Visual Studio 2019.

Теперь мы создадим наше простое веб-приложение ASP.NET Core, используя модель, представление и контроллер с входом пользователя.

Выберите веб-приложение (модель-представление-контроллер):

Нажмите «Изменить» рядом с «Проверка подлинности», выберите «Учетная запись отдельного пользователя» и нажмите «ОК».

Щелкните Создать, чтобы создать свой веб-проект.Мы видим, что наш первый веб-проект ASP.NET Core MVC был успешно создан с использованием Visual Studio 2019.

Мы можем увидеть страницу LoginPartial.cshtml в папке Views / Shared для новых участников. Регистрация и вход.

Изменение строки подключения

Здесь мы будем использовать наш SQL Server для хранения регистрации пользователя ASP.NET Identity для хранения значений в базе данных SQL. Для этого открываем файл appsettings.json и добавляем строку подключения.
Измените имя SQL Server на имя вашего SQL-сервера и измените UID и пароль на свой локальный SQL Server.



"ConnectionStrings": {

"DefaultConnection": "Сервер = ИМЯ_СЕРВЕРА; База данных = aspnetVS2019;

Trusted_Connection = True; MultipleActiveResultSets = true; User Id = ВАШ SQL UID;

& nbsp

Общие архитектуры веб-приложений | Документы Microsoft

  • 19 минут для чтения

В этой статье

«Если вы думаете, что хорошая архитектура стоит дорого, попробуйте плохую архитектуру."
- Брайан Фут и Джозеф Йодер

Большинство традиционных приложений .NET развертываются как отдельные блоки, соответствующие исполняемому файлу или одному веб-приложению, работающему в одном домене приложения IIS. Это простейшая модель развертывания, которая очень хорошо обслуживает множество внутренних и небольших общедоступных приложений. Однако даже с учетом этой единой единицы развертывания большинство нетривиальных бизнес-приложений выигрывают от некоторого логического разделения на несколько уровней.

Что такое монолитное приложение?

Монолитное приложение - это полностью автономное приложение с точки зрения его поведения.Он может взаимодействовать с другими службами или хранилищами данных в ходе выполнения своих операций, но ядро ​​его поведения выполняется внутри его собственного процесса, и все приложение обычно развертывается как единое целое. Если такое приложение необходимо масштабировать по горизонтали, обычно все приложение дублируется на нескольких серверах или виртуальных машинах.

Универсальные приложения

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

Новый проект ASP.NET Core, созданный в Visual Studio или из командной строки, начинается с простого монолита «все в одном». Он содержит все поведение приложения, включая логику представления, бизнеса и доступа к данным. На рис. 5-1 показана файловая структура приложения для одного проекта.

Рисунок 5-1. Приложение ASP.NET Core для одного проекта.

В сценарии одного проекта разделение задач достигается за счет использования папок.Шаблон по умолчанию включает отдельные папки для обязанностей шаблона MVC для моделей, представлений и контроллеров, а также дополнительные папки для данных и служб. При таком расположении детали представления должны быть максимально ограничены папкой Views, а детали реализации доступа к данным должны быть ограничены классами, хранящимися в папке Data. Бизнес-логика должна находиться в сервисах и классах в папке Models.

Простое монолитное решение для одного проекта имеет ряд недостатков.По мере роста размера и сложности проекта количество файлов и папок также будет расти. Проблемы пользовательского интерфейса (UI) (модели, представления, контроллеры) находятся в нескольких папках, которые не сгруппированы по алфавиту. Эта проблема только усугубляется, когда дополнительные конструкции уровня пользовательского интерфейса, такие как фильтры или ModelBinders, добавляются в их собственные папки. Бизнес-логика разбросана между папками Models и Services, и нет четкого указания, какие классы, в каких папках должны зависеть от других.Эта неорганизованность на уровне проекта часто приводит к спагетти-кода.

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

Что такое слои?

По мере того, как приложения становятся сложнее, один из способов справиться с этой сложностью - разбить приложение в соответствии с его обязанностями или задачами. Это соответствует принципу разделения задач и может помочь организовать растущую базу кода, чтобы разработчики могли легко найти, где реализованы определенные функции.Однако многоуровневая архитектура предлагает ряд преимуществ помимо простой организации кода.

За счет организации кода по уровням общие низкоуровневые функции можно повторно использовать во всем приложении. Это повторное использование выгодно, потому что оно означает, что нужно писать меньше кода, и потому, что оно может позволить приложению стандартизироваться для одной реализации, следуя принципу «не повторяйся» (DRY).

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

Слои

(и инкапсуляция) значительно упрощают замену функциональности в приложении. Например, приложение может изначально использовать свою собственную базу данных SQL Server для сохранения, но позже может выбрать стратегию сохранения на основе облака или стратегию за веб-API.Если приложение правильно инкапсулировало свою реализацию сохраняемости на логическом уровне, этот специфический для SQL Server уровень может быть заменен новым, реализующим тот же открытый интерфейс.

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

Логические уровни - это распространенный метод улучшения организации кода в корпоративных программных приложениях, и существует несколько способов организации кода в уровни.

Примечание

Уровни представляют собой логическое разделение в приложении. В случае, если логика приложения физически распределена по отдельным серверам или процессам, эти отдельные физические цели развертывания называются уровнями .Возможно и довольно часто бывает, что приложение N-уровня развертывается на одном уровне.

Приложения с традиционной "N-уровневой" архитектурой

Наиболее распространенная организация логики приложения по уровням показана на рисунке 5-2.

Рисунок 5-2. Типичные прикладные слои.

Эти уровни часто сокращенно обозначают как UI, BLL (уровень бизнес-логики) и DAL (уровень доступа к данным). Используя эту архитектуру, пользователи отправляют запросы через слой пользовательского интерфейса, который взаимодействует только с BLL.BLL, в свою очередь, может вызывать DAL для запросов доступа к данным. Уровень пользовательского интерфейса не должен делать какие-либо запросы к DAL напрямую, а также не должен напрямую взаимодействовать с персистентностью через другие средства. Точно так же BLL должен взаимодействовать с постоянством только через DAL. Таким образом, каждый уровень несет свою известную ответственность.

Одним из недостатков этого традиционного многоуровневого подхода является то, что зависимости времени компиляции выполняются сверху вниз. То есть уровень пользовательского интерфейса зависит от BLL, который зависит от DAL.Это означает, что BLL, который обычно содержит наиболее важную логику в приложении, зависит от деталей реализации доступа к данным (и часто от существования базы данных). Тестирование бизнес-логики в такой архитектуре часто бывает затруднительным и требует тестовой базы данных. Как вы увидите в следующем разделе, для решения этой проблемы можно использовать принцип инверсии зависимостей.

На рис. 5-3 показан пример решения, в котором приложение разбито на три проекта по ответственности (или уровням).

Рисунок 5-3. Простое монолитное приложение с тремя проектами.

Хотя это приложение использует несколько проектов для организационных целей, оно по-прежнему развертывается как единое целое, и его клиенты будут взаимодействовать с ним как с единым веб-приложением. Это позволяет упростить процесс развертывания. На рис. 5-4 показано, как такое приложение можно разместить с помощью Azure.

Рисунок 5-4. Простое развертывание веб-приложения Azure

По мере роста потребностей приложений могут потребоваться более сложные и надежные решения для развертывания.На рис. 5-5 показан пример более сложного плана развертывания, который поддерживает дополнительные возможности.

Рисунок 5-5. Развертывание веб-приложения в службе приложений Azure

Внутренняя организация этого проекта на несколько проектов на основе ответственности улучшает ремонтопригодность приложения.

Это устройство можно масштабировать или масштабировать, чтобы воспользоваться преимуществами масштабируемости на основе облака по требованию. Масштабирование означает добавление дополнительных ресурсов ЦП, памяти, дискового пространства или других ресурсов к серверам, на которых размещено ваше приложение.Масштабирование означает добавление дополнительных экземпляров таких серверов, будь то физические серверы, виртуальные машины или контейнеры. Когда ваше приложение размещено в нескольких экземплярах, балансировщик нагрузки используется для назначения запросов отдельным экземплярам приложения.

Самый простой подход к масштабированию веб-приложения в Azure - это настроить масштабирование вручную в плане службы приложений приложения. На рис. 5-6 показан соответствующий экран панели мониторинга Azure для настройки количества экземпляров, обслуживающих приложение.

Рисунок 5-6. Масштабирование плана службы приложений в Azure.

Чистая архитектура

Приложения, которые следуют принципу инверсии зависимостей, а также принципам доменно-ориентированного проектирования (DDD), как правило, приходят к аналогичной архитектуре. За прошедшие годы эта архитектура получила множество имен. Одним из первых названий была «Гексагональная архитектура», за которой последовали «Порты и адаптеры». Совсем недавно ее называли луковой архитектурой или чистой архитектурой.Последнее название, Чистая Архитектура, используется в качестве названия этой архитектуры в этой электронной книге.

Эталонное приложение eShopOnWeb использует подход чистой архитектуры для организации своего кода в проекты. Вы можете найти шаблон решения, который вы можете использовать в качестве отправной точки для своего собственного ASP.NET Core, в репозитории ardalis / cleanarchitecture GitHub.

Чистая архитектура ставит бизнес-логику и модель приложения в центр приложения. Вместо того, чтобы бизнес-логика зависела от доступа к данным или других проблем инфраструктуры, эта зависимость инвертируется: детали инфраструктуры и реализации зависят от ядра приложения.Это достигается путем определения абстракций или интерфейсов в ядре приложения, которые затем реализуются типами, определенными на уровне инфраструктуры. Распространенный способ визуализации этой архитектуры - использовать серию концентрических кругов, похожих на лук. На рис. 5-7 показан пример этого стиля архитектурного представления.

Рисунок 5-7. Чистая архитектура; лук вид

На этой диаграмме зависимости текут к самому внутреннему кругу.Ядро приложения берет свое название от его позиции в центре этой диаграммы. На диаграмме видно, что ядро ​​приложения не зависит от других уровней приложения. Сущности и интерфейсы приложения находятся в самом центре. Снаружи, но все еще в ядре приложения, находятся доменные службы, которые обычно реализуют интерфейсы, определенные во внутреннем круге. Вне ядра приложения уровни пользовательского интерфейса и инфраструктуры зависят от ядра приложения, но не друг от друга (обязательно).

На рис. 5-8 показана более традиционная диаграмма горизонтальных слоев, которая лучше отражает зависимость между пользовательским интерфейсом и другими уровнями.

Рисунок 5-8. Чистая архитектура; горизонтальный вид слоя

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

На рис. 5-9 показано более подробное представление архитектуры приложения ASP.NET Core, построенного в соответствии с этими рекомендациями.

Рисунок 5-9. Схема архитектуры ASP.NET Core в соответствии с чистой архитектурой.

Поскольку ядро ​​приложения не зависит от инфраструктуры, очень легко написать автоматизированные модульные тесты для этого уровня.На рисунках 5-10 и 5-11 показано, как тесты вписываются в эту архитектуру.

Рисунок 5-10. Модульное тестирование ядра приложения изолированно.

Рисунок 5-11. Интеграционное тестирование Реализации инфраструктуры с внешними зависимостями.

Поскольку уровень пользовательского интерфейса не имеет прямой зависимости от типов, определенных в проекте инфраструктуры, аналогично очень легко заменить реализации либо для облегчения тестирования, либо в ответ на изменение требований приложения.Встроенное в ASP.NET Core использование и поддержка внедрения зависимостей делает эту архитектуру наиболее подходящим способом структурирования нетривиальных монолитных приложений.

Для монолитных приложений все проекты Application Core, Infrastructure и UI выполняются как одно приложение. Архитектура рабочего приложения может выглядеть примерно так, как показано на рис. 5-12.

Рисунок 5-12. Образец архитектуры времени выполнения приложения ASP.NET Core.

Организационный код в чистой архитектуре

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

Ядро приложения

Ядро приложения содержит бизнес-модель, которая включает сущности, службы и интерфейсы. Эти интерфейсы включают абстракции для операций, которые будут выполняться с использованием инфраструктуры, таких как доступ к данным, доступ к файловой системе, сетевые вызовы и т. Д. Иногда службы или интерфейсы, определенные на этом уровне, должны будут работать с типами, не являющимися сущностями, которые не зависят от пользовательского интерфейса. или Инфраструктура.Их можно определить как простые объекты передачи данных (DTO).

Типы ядер приложений
  • Сущности (классы бизнес-модели, которые сохраняются)
  • Интерфейсы
  • Услуги
  • DTO
Инфраструктура

Проект инфраструктуры обычно включает реализации доступа к данным. В типичном веб-приложении ASP.NET Core эти реализации включают DbContext Entity Framework (EF), любые определенные объекты EF Core Migration и классы реализации доступа к данным.Наиболее распространенный способ абстрагирования кода реализации доступа к данным - использование шаблона проектирования репозитория.

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

Типы инфраструктуры
  • Типы ядра EF ( DbContext , Migration )
  • Типы реализации доступа к данным (репозитории)
  • Инфраструктурные службы (например, FileLogger или SmtpNotifier )
Уровень пользовательского интерфейса

Уровень пользовательского интерфейса в ASP.NET Core MVC - это точка входа для приложения. Этот проект должен ссылаться на проект Application Core, а его типы должны взаимодействовать с инфраструктурой строго через интерфейсы, определенные в Application Core. На уровне пользовательского интерфейса не должно быть разрешено прямое создание экземпляров или статические вызовы типов уровня инфраструктуры.

Типы слоев пользовательского интерфейса
  • Контроллеры
  • Фильтры
  • Просмотры
  • Модель
  • ViewModels
  • Запуск

Класс Startup отвечает за настройку приложения и подключение типов реализации к интерфейсам, что позволяет правильно работать с внедрением зависимостей во время выполнения.

Примечание

Чтобы подключить внедрение зависимостей в ConfigureServices в файле Startup.cs проекта пользовательского интерфейса, проекту может потребоваться ссылка на проект инфраструктуры. Эту зависимость можно устранить, проще всего с помощью настраиваемого контейнера DI. Для целей этого примера самый простой подход - разрешить проекту пользовательского интерфейса ссылаться на проект инфраструктуры.

Монолитные приложения и контейнеры

Вы можете создать единое и монолитное веб-приложение или службу на основе развертывания и развернуть их как контейнер.Внутри приложения он может быть не монолитным, а организован в несколько библиотек, компонентов или слоев. Внешне это единый контейнер, такой как отдельный процесс, одно веб-приложение или отдельная служба.

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

В каждый контейнер можно включить несколько компонентов / библиотек или внутренних слоев, как показано на рисунке 5-13.Но, следуя принципу контейнера «контейнер делает одно дело, а делает это в одном процессе », монолитный шаблон может вызвать конфликт.

Обратная сторона этого подхода проявляется, если / когда приложение растет, требуя его масштабирования. Если все приложение масштабируется, это не проблема. Однако в большинстве случаев некоторые части приложения представляют собой узкие места, требующие масштабирования, в то время как другие компоненты используются меньше.

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

Помимо проблемы «масштабирования всего», изменения в одном компоненте требуют полного повторного тестирования всего приложения и полного повторного развертывания всех экземпляров.

Монолитный подход является распространенным, и многие организации развивают этот архитектурный подход. Многие достигают достаточно хороших результатов, в то время как другие достигают пределов. Многие разрабатывали свои приложения в этой модели, потому что инструменты и инфраструктура были слишком сложными для построения сервис-ориентированных архитектур (SOA), и они не видели необходимости, пока приложение не выросло. Если вы обнаружите, что выходите за пределы монолитного подхода, следующим логическим шагом может стать разделение приложения, чтобы оно могло лучше использовать контейнеры и микросервисы.

Развертывание монолитных приложений в Microsoft Azure может быть достигнуто с помощью выделенных виртуальных машин для каждого экземпляра. Используя масштабируемые наборы виртуальных машин Azure, вы можете легко масштабировать виртуальные машины. Службы приложений Azure могут запускать монолитные приложения и легко масштабировать экземпляры без необходимости управлять виртуальными машинами. Службы приложений Azure также могут запускать отдельные экземпляры контейнеров Docker, что упрощает развертывание. Используя Docker, вы можете развернуть одну виртуальную машину в качестве хоста Docker и запустить несколько экземпляров.Используя балансировщик Azure, как показано на рисунке 5-14, вы можете управлять масштабированием.

Развертыванием на различные хосты можно управлять с помощью традиционных методов развертывания. Хостами Docker можно управлять с помощью таких команд, как docker run , выполняемых вручную, или посредством автоматизации, такой как конвейеры непрерывной доставки (CD).

Монолитное приложение, развернутое как контейнер

Есть преимущества использования контейнеров для управления развертыванием монолитных приложений.Масштабирование экземпляров контейнеров намного быстрее и проще, чем развертывание дополнительных виртуальных машин. Даже при использовании масштабируемых наборов виртуальных машин для масштабирования виртуальных машин требуется время для создания экземпляра. При развертывании в виде экземпляров приложения конфигурация приложения управляется как часть виртуальной машины.

Развертывание обновлений в виде образов Docker происходит намного быстрее и эффективнее в сети. Образы Docker обычно запускаются за секунды, что ускоряет развертывание. Разорвать экземпляр Docker так же просто, как выполнить команду docker stop , которая обычно выполняется менее чем за секунду.

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

Вы можете использовать контейнеры Docker для монолитного развертывания более простых веб-приложений. Это улучшает конвейеры непрерывной интеграции и непрерывного развертывания и помогает добиться успеха от развертывания к производственной среде. Больше никаких «Это работает на моей машине, почему не работает в производстве?»

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

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

Возможно, приложению еще не требуется масштабировать функции независимо.Многие приложения, когда им необходимо масштабироваться за пределы одного экземпляра, могут сделать это с помощью относительно простого процесса клонирования всего экземпляра. Дополнительная работа по разделению приложения на отдельные службы дает минимальные преимущества при простом и экономичном масштабировании полных экземпляров приложения.

На раннем этапе разработки приложения вы можете не иметь четкого представления о естественных функциональных границах. Поскольку вы разрабатываете минимально жизнеспособный продукт, естественное разделение может еще не возникнуть.Некоторые из этих условий могут быть временными. Вы можете начать с создания монолитного приложения, а затем отделить некоторые функции, которые будут разработаны и развернуты как микросервисы. Другие условия могут быть важны для проблемного пространства приложения, что означает, что приложение никогда не может быть разбито на несколько микросервисов.

Разделение приложения на множество отдельных процессов также приводит к накладным расходам. Сложнее разделить функции на разные процессы. Протоколы связи становятся более сложными.Вместо вызовов методов вы должны использовать асинхронную связь между службами. При переходе к архитектуре микросервисов вам необходимо добавить многие строительные блоки, реализованные в микросервисной версии приложения eShopOnContainers: обработка шины событий, отказоустойчивость и повторные попытки сообщений, конечная согласованность и многое другое.

Намного более простое эталонное приложение eShopOnWeb поддерживает использование монолитного контейнера с одним контейнером. Приложение включает в себя одно веб-приложение, которое включает традиционные представления MVC, веб-API и страницы Razor.Это приложение можно запустить из корня решения с помощью команд docker-compose build и docker-compose up . Эта команда настраивает контейнер для веб-экземпляра, используя Dockerfile , найденный в корне веб-проекта, и запускает контейнер на указанном порту. Вы можете загрузить исходный код этого приложения с GitHub и запустить его локально. Даже это монолитное приложение выигрывает от развертывания в контейнерной среде.

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

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

Наконец, контейнеризация приложения приводит к разделению бизнес-логики и сервера хранения.По мере масштабирования приложения все несколько контейнеров будут полагаться на один физический носитель. Этот носитель обычно представляет собой сервер высокой доступности, на котором работает база данных SQL Server.

Поддержка докеров

Проект eShopOnWeb работает на .NET Core. Следовательно, он может работать в контейнерах на базе Linux или Windows. Обратите внимание, что для развертывания Docker вы хотите использовать тот же тип хоста для SQL Server. Контейнеры на базе Linux занимают меньше места и являются предпочтительными.

Вы можете использовать Visual Studio 2017 или более поздней версии, чтобы добавить поддержку Docker в существующее приложение, щелкнув правой кнопкой мыши проект в Solution Explorer и выбрав Добавить > Поддержка Docker . Это добавляет необходимые файлы и модифицирует проект для их использования. В текущем образце eShopOnWeb эти файлы уже есть.

Файл docker-compose.yml уровня решения содержит информацию о том, какие образы нужно создавать и какие контейнеры запускать.Этот файл позволяет использовать команду docker-compose для одновременного запуска нескольких приложений. В данном случае это только запуск веб-проекта. Вы также можете использовать его для настройки зависимостей, таких как отдельный контейнер базы данных.

  версия: '3'

Сервисы:
  eshopwebmvc:
    изображение: eshopwebmvc
    сборка:
      контекст:.
      dockerfile: src / Web / Dockerfile
    Окружающая среда:
      - ASPNETCORE_ENVIRONMENT = Разработка
    порты:
      - «5106: 5106»

сети:
  по умолчанию:
    внешний:
      имя: нат
  

Файл docker-compose.yml ссылается на Dockerfile в проекте Web . Dockerfile используется для указания, какой базовый контейнер будет использоваться и как приложение будет настроено на нем. Web ' Dockerfile :

  ИЗ mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR / приложение

КОПИРОВАТЬ * .sln.
КОПИРОВАТЬ. .
WORKDIR / приложение / src / Интернет
RUN dotnet restore

RUN dotnet publish -c Release -o out

ИЗ mcr.microsoft.com/dotnet/core/aspnet:3.1 среда выполнения AS
WORKDIR / приложение
КОПИРОВАТЬ --from = build / app / src / Web / out ./

ENTRYPOINT ["dotnet", "Web.dll"]
  

Устранение неполадок Docker

После запуска контейнерного приложения оно продолжает работать, пока вы его не остановите. Вы можете просмотреть, какие контейнеры запущены, с помощью команды docker ps . Вы можете остановить работающий контейнер, используя команду docker stop и указав идентификатор контейнера.

Обратите внимание, что запущенные контейнеры Docker могут быть привязаны к портам, которые в противном случае вы могли бы попытаться использовать в своей среде разработки.Если вы попытаетесь запустить или отладить приложение, используя тот же порт, что и запущенный контейнер Docker, вы получите сообщение об ошибке о том, что сервер не может выполнить привязку к этому порту. Еще раз, остановка контейнера должна решить проблему.

Если вы хотите добавить поддержку Docker в свое приложение с помощью Visual Studio, убедитесь, что Docker Desktop запущен, когда вы это делаете. Мастер не будет работать правильно, если Docker Desktop не запущен при запуске мастера. Кроме того, мастер проверяет ваш текущий выбор контейнера, чтобы добавить правильную поддержку Docker.Если вы хотите добавить поддержку контейнеров Windows, вам необходимо запустить мастер, когда у вас есть рабочий стол Docker с настроенными контейнерами Windows. Если вы хотите добавить поддержку контейнеров Linux, запустите мастер, пока Docker работает с настроенными контейнерами Linux.

Ссылки - Общие веб-архитектуры

Создайте свою первую клиентскую веб-часть SharePoint (Hello World, часть 1)

  • 11 минут на чтение

В этой статье

Клиентские веб-части - это клиентские компоненты, которые запускаются в контексте страницы SharePoint.Клиентские веб-части можно развертывать в средах SharePoint, поддерживающих SharePoint Framework. Вы также можете использовать современные веб-фреймворки, инструменты и библиотеки JavaScript для их создания.

Поддержка клиентских веб-частей:

  • Строительство с помощью HTML и JavaScript.
  • И SharePoint Online, и локальная среда.

Вы также можете выполнить следующие действия, просмотрев это видео на канале SharePoint PnP YouTube:

Создать новый проект веб-части

  1. Создайте новый каталог проекта в вашем любимом месте.

      мкр helloworld-webpart
      
  2. Перейти в каталог проекта.

      компакт-диск helloworld-webpart
      
  3. Создайте новую веб-часть HelloWorld, запустив Yeoman SharePoint Generator.

      лет @ microsoft / sharepoint
      
  4. При запросе:

    • Как называется ваше решение? : helloworld-webpart
    • Какие базовые пакеты вы хотите настроить для своих компонентов? : только SharePoint Online (последняя версия)
    • Где вы хотите разместить файлы? : использовать текущую папку
    • Вы хотите предоставить администратору клиента возможность немедленного развертывания решения на всех сайтах без запуска каких-либо функций или добавления приложений на сайты? : N
    • Потребуются ли для компонентов в решении разрешения для доступа к уникальным веб-API, которые не используются другими компонентами в клиенте? : N
    • Какой тип клиентского компонента создать? : Веб-часть
  5. Следующий набор запросов запрашивает конкретную информацию о вашей веб-части:

    • Как называется ваша веб-часть? : HelloWorld
    • Какое описание вашей веб-части? : Описание HelloWorld
    • Какой фреймворк вы хотите использовать? : Нет фреймворка JavaScript

На этом этапе Yeoman создает каркас проекта (папки и файлы) и устанавливает необходимые зависимости, запустив npm install .Обычно это занимает 1-3 минуты в зависимости от вашего интернет-соединения.

Когда процесс установки шаблонов и зависимостей проекта будет завершен, Yeoman отобразит сообщение, подобное следующему, указывающее, что он был успешным:

Важно

NPM может отображать предупреждения и сообщения об ошибках во время установки зависимостей, когда он выполняет команду npm install . Вы можете спокойно игнорировать эти предупреждения и сообщения об ошибках в журнале.

NPM может отображать сообщение о запуске npm audit в конце процесса.Не запускайте эту команду, так как она обновит пакеты и вложенные зависимости, которые, возможно, не были протестированы SharePoint Framework.

Для получения информации об устранении любых ошибок см. Известные проблемы.

Используйте свой любимый редактор кода

Поскольку клиентское решение SharePoint основано на HTML / TypeScript, для создания веб-части можно использовать любой редактор кода, поддерживающий разработку на стороне клиента, например:

В документации по SharePoint Framework в шагах и примерах используется код Visual Studio.Visual Studio Code (VS Code) - это легкий, но мощный редактор исходного кода от Microsoft, который работает на вашем рабочем столе. VS Code доступен для Windows, macOS и Linux. Он поставляется со встроенной поддержкой JavaScript, TypeScript, Node.js и имеет богатую экосистему расширений для других языков (таких как C ++, C #, Python, PHP) и среды выполнения.

Предварительный просмотр веб-части

Вы можете предварительно просмотреть и протестировать клиентскую веб-часть локально на своей рабочей станции. Инструментальная цепочка на стороне клиента по умолчанию использует конечную точку HTTPS.Часть процесса настройки среды разработки включала в себя доверие SSL-сертификату разработки, включенному в цепочку инструментов в вашей локальной среде. Это необходимо, чтобы ваш браузер доверял сертификату.

Теперь, когда мы установили сертификат разработчика, введите в консоли следующую команду для создания и предварительного просмотра веб-части:

  порция глотком
  

Эта команда выполняет серию задач gulp для создания и запуска локального веб-сервера, на котором размещаются конечные точки localhost: 4321 и localhost: 5432 .Затем он откроет ваш браузер по умолчанию и загрузит веб-части предварительного просмотра рабочей среды из вашей локальной среды разработки.

Инструменты разработки на стороне клиента SharePoint используют gulp в качестве средства выполнения задач для обработки таких задач процесса сборки, как:

  • Компиляция файлов TypeScript в JavaScript.
  • Компиляция файлов SASS в CSS.
  • Объединение и минимизация файлов JavaScript и CSS.

VS Code обеспечивает встроенную поддержку gulp и других исполнителей задач.Выберите CTRL + SHIFT + B в Windows или CMD + SHIFT + B в macOS для отладки и предварительного просмотра веб-части.

SharePoint Workbench - это рабочая среда для разработчиков, которая позволяет быстро просматривать и тестировать веб-части, не развертывая их в SharePoint. SharePoint Workbench включает клиентскую страницу и холст на стороне клиента, на котором вы можете добавлять, удалять и тестировать свои веб-части в процессе разработки.

Используйте SharePoint Workbench для предварительного просмотра и тестирования веб-части

  1. Чтобы добавить веб-часть HelloWorld, выберите значок добавить ( этот значок появляется, когда вы наводите курсор мыши на раздел, как показано на изображении выше ).Откроется панель инструментов, где вы увидите список веб-частей, которые вы можете добавить. Список включает веб-часть HelloWorld , а также другие веб-части, доступные локально в вашей среде разработки.

  2. Выберите HelloWorld , чтобы добавить веб-часть на страницу.

    Поздравляем! Вы только что добавили свою первую клиентскую веб-часть на клиентскую страницу.

  3. Щелкните значок карандаша в дальнем левом углу веб-части, чтобы открыть панель свойств веб-части.

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

  4. Измените текст в текстовом поле Описание на Клиентские веб-части - это здорово!

    Обратите внимание, как текст в веб-части также изменяется при вводе.

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

Структура проекта веб-части

Использование кода Visual Studio для изучения структуры проекта веб-части

  1. В консоли остановите локальный веб-сервер, завершив процесс. Выбор CTRL + C в Windows или macOS.

  2. Введите следующую команду, чтобы открыть проект веб-части в VS Code (или используйте свой любимый редактор):

      код. 

TypeScript - это основной язык для создания клиентских веб-частей SharePoint. TypeScript - это типизированный надмножество JavaScript, которое компилируется в простой JavaScript. Инструменты разработки на стороне клиента SharePoint созданы с использованием классов, модулей и интерфейсов TypeScript, чтобы помочь разработчикам создавать надежные веб-части на стороне клиента.

Ниже приведены некоторые ключевые файлы проекта.

Класс веб-части

HelloWorldWebPart.ts в папке src \ webparts \ helloworld определяет основную точку входа для веб-части.Класс веб-части HelloWorldWebPart расширяет BaseClientSideWebPart . Любая клиентская веб-часть должна расширять класс BaseClientSideWebPart , чтобы его можно было определить как допустимую веб-часть.

BaseClientSideWebPart реализует минимальную функциональность, необходимую для создания веб-части. Этот класс также предоставляет множество параметров для проверки и доступа к свойствам, доступным только для чтения, таким как displayMode , свойства веб-части, контекст веб-части, веб-часть instanceId , веб-часть domElement и многое другое.

Обратите внимание, что класс веб-части определен для приема типа свойства IHelloWorldWebPartProps .

Тип свойства определяется как интерфейс перед классом HelloWorldWebPart в файле HelloWorldWebPart.ts .

  интерфейс экспорта IHelloWorldWebPartProps {
  описание: строка;
}
  

Это определение свойства используется для определения типов настраиваемых свойств для веб-части, которые описаны в разделе панели свойств ниже.

Метод визуализации веб-части

Элемент DOM, в котором должна отображаться веб-часть, доступен в методе render () . Этот метод используется для визуализации веб-части внутри этого элемента DOM. В веб-части HelloWorld элемент DOM установлен в DIV. Параметры метода включают режим отображения (чтение или изменение) и настроенные свойства веб-части, если таковые имеются:

  public render (): void {
  this.domElement.innerHTML = `
    
Добро пожаловать в SharePoint!

Настройте взаимодействие с SharePoint с помощью веб-частей.

$ {escape (this.properties.description)}

Узнать больше
`; }

Эта модель достаточно гибкая, так что веб-части можно создавать в любой среде JavaScript и загружать в элемент DOM.

Настроить панель свойств веб-части

Панель свойств определена в классе HelloWorldWebPart .Свойство getPropertyPaneConfiguration - это то место, где вам нужно определить панель свойств.

Когда свойства определены, вы можете получить к ним доступ в своей веб-части, используя this.properties. , как показано в методе render () :

  

$ {escape (this.properties.description)}

Обратите внимание, что мы выполняем экранирование HTML для значения свойства, чтобы гарантировать правильную строку. Дополнительные сведения о работе с типами полей панели свойств и панели свойств см. В разделе Настройка настраиваемой клиентской веб-части SharePoint.

Давайте теперь добавим еще несколько свойств на панель свойств: флажок, раскрывающийся список и переключатель. Сначала мы начнем с импорта соответствующих полей панели свойств из фреймворка.

  1. Прокрутите файл до верхней части и добавьте следующее в раздел импорта из @ microsoft / sp-property-pane :

      PropertyPaneCheckbox,
    PropertyPaneDropdown,
    PropertyPaneToggle
      

    Полный раздел импорта выглядит следующим образом:

      импорт {
      IPropertyPaneConfiguration,
      PropertyPaneTextField,
      PropertyPaneCheckbox,
      PropertyPaneDropdown,
      PropertyPaneToggle
    } из '@ microsoft / sp-property-pane';
      
  2. Обновите свойства веб-части, чтобы включить новые свойства.Это сопоставляет поля с типизированными объектами.

  3. Замените интерфейс IHelloWorldWebPartProps следующим кодом.

      интерфейс экспорта IHelloWorldWebPartProps {
      описание: строка;
      тест: строка;
      test1: логический;
      test2: строка;
      test3: логический;
    }
      
  4. Сохраните файл.

  5. Замените метод getPropertyPaneConfiguration () следующим кодом, который добавляет новые поля панели свойств и сопоставляет их с соответствующими типизированными объектами.

      защищенный getPropertyPaneConfiguration (): IPropertyPaneConfiguration {
      возвращение {
        страницы: [
          {
            header: {
              описание: strings.PropertyPaneDescription
            },
            группы: [
              {
                groupName: strings.BasicGroupName,
                groupFields: [
                PropertyPaneTextField ('описание', {
                  label: "Описание"
                }),
                PropertyPaneTextField ('test', {
                  label: 'Многострочное текстовое поле',
                  многострочный: true
                }),
                PropertyPaneCheckbox ('test1', {
                  текст: 'Флажок'
                }),
                PropertyPaneDropdown ('test2', {
                  label: "Раскрывающийся список",
                  параметры: [
                    {ключ: '1', текст: 'Один'},
                    {ключ: '2', текст: 'Два'},
                    {ключ: '3', текст: 'Три'},
                    {ключ: '4', текст: 'Четыре'}
                  ]}),
                PropertyPaneToggle ('test3', {
                  label: 'Переключить',
                  onText: 'Вкл',
                  offText: 'Выкл.'
                })
              ]
              }
            ]
          }
        ]
      };
    }
      
  6. После добавления свойств к свойствам веб-части теперь вы можете получить доступ к свойствам так же, как вы обращались к свойству description ранее:

      

    $ {escape (this.properties.test)}

    Чтобы установить значение по умолчанию для свойств, необходимо обновить пакет свойств свойств манифеста веб-части.

  7. Откройте HelloWorldWebPart.manifest.json и измените свойства на:

      "свойства": {
      "description": "HelloWorld",
      "test": "Многострочное текстовое поле",
      "test1": правда,
      "test2": "2",
      "test3": верно
    }
      

Панель свойств веб-части теперь имеет эти значения по умолчанию для этих свойств.

Манифест веб-части

Файл HelloWorldWebPart.manifest.json определяет метаданные веб-части, такие как версия, идентификатор, отображаемое имя, значок и описание. Каждая веб-часть должна содержать этот манифест.

  {
  «$ schema»: «https://developer.microsoft.com/json-schemas/spfx/client-side-web-part-manifest.schema.json»,
  "id": "fbcf2c6a-7df9-414c-b3f5-37cab6bb1280",
  "псевдоним": "HelloWorldWebPart",
  "componentType": "WebPart",

  // "*" означает, что версия должна быть взята из пакета.json
  "версия": "*",
  "manifestVersion": 2,

  // Если true, компонент может быть установлен только на сайтах, где разрешен Custom Script.
  // Компоненты, которые позволяют авторам встраивать произвольный код сценария, должны установить это значение true.
  // https://support.office.com/article/Turn-scripting-capabilities-on-or-off-1f2c515f-5d7e-448a-9fd7-835da935584f
  "requiresCustomScript": ложь,
  "supportedHosts": ["SharePointWebPart"],

  "preconfiguredEntries": [{
    "groupId": "5c03119e-3074-46fd-976b-c60198311f70", // Другое
    "group": {"default": "Other"},
    "title": {"default": "HelloWorld"},
    "description": {"default": "HelloWorld description"},
    "officeFabricIconFontName": "Страница",
    "properties": {
      "description": "HelloWorld",
      "test": "Многострочное текстовое поле",
      "test1": правда,
      "test2": "2",
      "test3": верно
    }
  }]
}
  

Теперь, когда мы ввели новые свойства, убедитесь, что вы снова размещаете веб-часть из локальной среды разработки, выполнив следующую команду.Это также гарантирует, что предыдущие изменения были применены правильно.

  порция глотком
  

Предварительный просмотр веб-части в рабочей среде SharePoint

SharePoint Workbench также размещен в SharePoint для предварительного просмотра и тестирования локальных веб-частей в процессе разработки. Ключевым преимуществом является то, что теперь вы работаете в контексте SharePoint и можете взаимодействовать с данными SharePoint.

  1. Перейдите по следующему URL-адресу: https: // your-sharepoint-tenant.sharepoint.com/_layouts/workbench.aspx

    Примечание

    Если у вас не установлен сертификат разработчика SPFx, Workbench уведомит вас о том, что он настроен так, чтобы не загружать скрипты с localhost. Остановите текущий запущенный процесс в окне консоли и выполните команду gulp trust-dev-cert в консоли каталога проекта, чтобы установить сертификат разработчика, перед повторным запуском команды gulp serve . Дополнительные сведения см. В разделе Доверие самозаверяющему сертификату разработчика

    .

  2. Обратите внимание, что в SharePoint Workbench теперь есть панель навигации Office 365 Suite.

  3. Выберите значок добавить на холсте, чтобы открыть панель инструментов. На панели инструментов теперь отображаются веб-части, доступные на сайте, на котором размещена SharePoint Workbench, вместе с вашим HelloWorldWebPart .

  4. Добавьте HelloWorld из панели инструментов. Теперь вы запускаете свою веб-часть на странице, размещенной в SharePoint!

Примечание

Цвет веб-части зависит от цветов сайта.По умолчанию веб-части наследуют основные цвета с сайта, динамически ссылаясь на стили Office UI Fabric Core, используемые на сайте, где размещена веб-часть.

Поскольку вы все еще разрабатываете и тестируете свою веб-часть, нет необходимости упаковывать и развертывать веб-часть в SharePoint.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *