Fruitsekta.ru

Мир ПК
1 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

C архитектура приложений

Краткий обзор 10 популярных архитектурных шаблонов приложений

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

Что такое архитектурный шаблон?

По материалам Википедии,

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

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

1. Многоуровневый шаблон

2. Клиент-серверный шаблон

4. Каналы и фильтры

5. Шаблон посредника

6. Одноранговый шаблон

1. Многоуровневый шаблон

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

Чаще всего в общих информационных системах встречаются следующие 4 слоя:

· Слой представления (также известен как слой пользовательского интерфейса)

· Слой приложения (также известен как слой сервиса)

· Слой бизнес-логики (также известен как уровень предметной области)

· Слой доступа к данным (также известен как уровень хранения данных)

Использование

· Общие десктопные приложения.

2. Клиент-серверный шаблон

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

Использование

· Онлайн приложения (электронная почта, совместный доступ к документам, банковские услуги).

3. Ведущий-ведомый

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

Использование

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

· Периферийные устройства, подключенные к шине в компьютере (ведущие и ведомые устройства).

4. Каналы и фильтры

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

Использование

· Компиляторы. Последовательные фильтры выполняют лексический, синтаксический, семантический анализ и создание кода.

· Рабочие процессы в биоинформатике.

5. Шаблон посредника

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

Сервер размещает свои возможности (службы и характеристики) у посредника (брокера). Клиент запрашивает услугу у брокера. Затем брокер перенаправляет клиента к подходящей службе из своего реестра.

Использование

6. Одноранговый шаблон

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

Использование

· Проприетарные мультимедийные приложения (как тот же Spotify).

7. Шина событий

Этот шаблон, в основном, взаимодействует с событиями и состоит из 4 главных компонентов: источник события, прослушиватель события, канал и шина событий. Источники размещают сообщения для определенных каналов на шине событий. Прослушиватели подписываются на определенные каналы. Прослушиватели получают уведомления о появлении сообщений, размещенных на каналах из их подписки.

Использование

· Разработки на Android

8. Модель-представление-контроллер

Этот шаблон также известен как MVC-шаблон. Он разделяет интерактивные прикладные программы на 3 части:

1. модель — содержит ключевые данные и функционал;

2. представление — показывает информацию пользователю (можно задавать более одного представления);

3. контроллер — занимается обработкой данных от пользователя.

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

Использование

· Архитектура WWW-приложений, написанных на основных языках программирования.

9. Доска

Такой шаблон подходит для проблем, для которых отсутствуют четкие детерминированные решения. Шаблон «Доска» состоит из 3 главных компонентов:

· доска — это структурированная глобальная память, содержащая объекты из пространства возможных решений;

· источник знания — специализированные модули со своим собственным представлением;

· компоненты управления — выбирает, настраивает и исполняет модули.

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

Использование

· идентификация и отслеживание транспортных средств;

· определение структур белка;

· интерпретация сигналов Sonar.

10. Интерпретатор

Он подходит для разработки компонента, который должен интерпретировать программы, написанные на специальном языке программирования. В основном, там расписано, как вычислять строки (иначе говоря: «предложения» или «выражения»), написанные на каком-то определенном языке программирования. Суть в том, чтобы присвоить класс каждому символу языка.

Использование

· языки запросов к базе данных (SQL);

· языки, которые используются для описания протоколов передачи данных.

Сравнение архитектурных шаблонов

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

Многоуровневый шаблон

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

Клиент-серверный шаблон

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

Шаблон «Ведущий-ведомый»

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

Шаблон «Каналы и фильтры»

  • Могут реализовывать параллельные процессы, когда вход и выход состоит из потоков, а фильтры начинают вычисления после получения данных.
  • Простое добавление фильтров. Систему можно легко расширить.
  • Фильтры подходят для повторного использования. Могут выстраивать различные конвейеры, создавая всевозможные комбинации существующего набора фильтров.
  • Эффективность снижается из-за самых медленных процессов фильтрации. При переходе от одного фильтра к другому выполняется трансформация данных, которая ведет к повышенному потреблению ресурсов.
Читать еще:  Архитектура глобальной сети

Шаблон «Посредник»

  • Возможно динамическое изменение, добавление, удаление и перемещение объектов. Этот шаблон делает процесс распределения прозрачным для разработчика.
  • Необходима стандартизация описаний служб.

Одноранговый шаблон

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

Шаблон «Шина событий»

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

Шаблон «Модель-представление-контроллер»

  • Упрощает создание различных представлений одной и той же модели; их можно включить или отключить на этапе выполнения.
  • Возрастает сложность алгоритма. Может привести ко многим ненужным корректировкам действий пользователей.

Шаблон «Доска»

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

Шаблон «Интерпретатор»

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

Архитектура приложений

Архитектура приложений

Контекст и основные элементы архитектуры приложений

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

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

В Архитектуре приложений, как правило, выделяют две основные области [4.3]:

  • формирование и управление портфелем прикладных систем предприятия;
  • разработку прикладных систем.

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

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

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

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

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

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

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

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

Контекст управления портфелем прикладных систем показан на рис. 6.2.

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

Читать еще:  Документы в архитектуре

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

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

Архитектура приложений

Onion-архитектура. Часть 1

Термин «Onion Architecture» («луковая» архитектура) был предложен Джеффри Палермо (Jeffrey Palermo) еще в 2008 году. Спустя годы данная концепция стала довольно популярной и является одной из наиболее применяемых типов архитектуры при построении приложения на ASP.NET.

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

Количество уровней может отличаться, но в центре всегда находится модель домена (Domain Model), то есть те классы моделей, которые используются в приложении и объекты которых хранятся в базе данных:

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

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

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

Для более подробного рассмотрения данного типа архитектуры создадим обычный проект ASP.NET MVC 5, который будет называться OnionApp.

Пока это монолитное приложение, в котором весь код размещен в одном проекте. Теперь добавим в решение (не в проект) новую папку. Назовем ее Domain . Затем добавим в папку новый проект. В качестве типа проекта выберем тип Class Library , а в качестве его названия укажем OnionApp.Domain.Core :

Добавим в новый проект класс, представляющий книгу, который и будут представлять Domain Model:

Затем добавим в папку Domain новый проект также по типу >OnionApp.Domain.Interfaces . Затем добавим в этот проект ссылку на вышеопределенный проект OnionApp.Domain.Core и также добавим новый интерфейса:

Этот интерфейс и составляет уровень Domain Services и зависит от уровня Domain Model.

И на данный момент проекты выглядят так:

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

На выше представленной схеме между внешним уровнем и уровнем Domain Services есть еще уровень API или интерфейсов бизнес-логики приложения — уровень Application Services. Этот уровень может включать интерфейсы вспомогательных классов. Например, покупка книги может представлять собой объект, который в зависимости от способа оплата (наличкой, через кредитную карту, через электронные деньги) может включать тот или иной функционал. И, возможно, было бы неплохо определить общий интерфейс покупки, а в зависимости от типа магазина использовать его конкретную реализацию. Поэтому добавим в решение новую папку, которую назовем Services . В эту папку добавим новый проект по типу >OnionApp.Services.Interfaces

И добавим в этот проект интерфейс IOrder:

Данный проект также имеет зависимость от классов проекта OnionApp.Domain.Core . А интерфейс IOrder, представляющий процесс покупки и оформления заказа, использует эти классы в методе MakeOrder() . Предполагается, что в метод передается объект купленной книги.

Теперь перейдем к созданию внешнего уровня, который и будет реализовывать данные интерфейсы. Для этого добавим в решение папку Infrastructure и затем в нее добавим новый проект по типу >OnionApp.Infrastructure.Data .

Данный проект будет реализовывать интерфейсы, объявленные на нижних уровнях, и связывать их с хранилищем данных. В качестве хранилища данных будет использоваться бд MS SQL Server, с которой мы будем взаимодействовать через Entity Framework. Поэтому добавим в этот проект через nuGet все пакеты Entity Framework. Также добавим в проект ссылки на проекты OnionApp.Domain.Core и OnionApp.Domain.Interfaces.

После этого добавим в проект новый класс OrderContext :

Также добавим класс репозитория BookRepository:

Архитектура приложений: концептуальные слои и договоренности по их использованию

ru-RU | создано: 03.02.2017 | опубликовано: 03.02.2017 | обновлено: 23.03.2019 | просмотров за всё время: 6246

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

Пример договоренностей

Разберем для примера общеизвестный фреймворк ASP.NET MVC. Если вы работали с этой системой, то наверное обратили внимание на то, что в проекте, который создается Visual Studio по умолчанию присутствуют папки Models, Views, Controllers. Это первая договоренность, что каждый тип файла (класса) лежит в своей собственной папке.

В первых версиях фреймворка ASP.NET MVC контролеры могли лежать только в папке Controllers. Позже это ограничение было снято.

Eсли при разработки какого-либо метода контролера вы попробуете создать метод и открыть его, не создав представление (View) этого метода, то система выдаст вам сообщение об ошибке:

Обратите внимание на то, где система попыталась найти «потерянное» представление, прежде чем выдать сообщение. Такое поведение также предопределено договоренностями фреймворка. В данном случае, правило гласит, что если представление (View) не найдено в папке контролера Home, то следует ее поискать сначала в папке Shared, потом всё то же самое, но уже с другим расширением для другого движка рендеринга (при наличии подключенных нескольких движков рендеринга разметки). На самом деле договоренностей подобного рода в ASP.NET MVC очень большое количество. И тем больше вы их будете встречать, чем глубже будете погружаться в «дебри» фреймворка.

Читать еще:  Разработка архитектуры по

ASP.NET MVC фреймворк как и все фреймворки, во всяком случае в большинстве своем, построены на основе парадигмы «соглашения по конфигрурации» (configuration over convention).

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

Суть данной статьи показать, что использование упомянутой выше парадигмы применительно к коллективной разработке, может существенно ускорить (упростить) процесс разработки приложений, особенно если в разработке учавствует большое количество разработчиков. «Соглашения по конфигурации» позволяют решить вопросы, на которые зачастую тратятся драгоценные минуты, часы и даже дни и недели. Например, часто возникает вопрос, как правильно назвать создаваемый класс, свойство, метод, проект, переменную, решение (solution)? Сколько разработчиков, столько и вариантов, если не договорится заранее о правилах именования. А если в коллектив пришел новый разработчик, то как он может начать писать корректный код, не зная о правилах, по которым этот код пишется? Безусловно, существуют огромное количество вспомогательных утилит (например, StyleCop), которые упрощают задачу, но и они бывают бессильны в некоторых случаях.

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

Немного истории

В качестве примера нарастания сложности, приведу эволюцию паттернов Business Logic, которые описывают, как и где дожна быть релизована бизнес-логика. Паттерны для организации бизнес-уровеня (бизнес-логика) с течением времени претерпели существенные изменения, от простого к сложному. Более того, на этом эволюция не остановилась.

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

Что говорить, если уже не только среди разработчиков, но и среди заказчиков всё чаще и чаще слышатся подобные слова и фразы: ORM, Repository, Business Layer, Abstraction​ и Dependency Injection, MVVM и другие.

Среди разработчиков ходят давнишние споры относительно того, следует ли использовать дополнительную «прослойку» типа ORM между базами данных и DAL. Например, на sql.ru или на habrahabr.ru частенько поднимаются темы. Лейтмотивом в подобных спорах звучит мысль: «. для сложных проектов использование ORM существенно сокращает рутину. «.

Так повелось, что с некоторого времени я перестал разделять проекты на сложные и простые, взяв за основу использование ORM для проектов любой сложности. Особенно если учесть, что ORM позволяет использовать подход CodeFirst (в частности, EntityFramework).

Осмелюсь предположить, что вы уже знакомы с паттернами проектирования, и в частности, с паттернами Repository и UnitOfWork, именно на их основе я и буду говорить о договоренностях для построения уровня доступа к данным (Data Access Layer). А также предположу, что вы имеете представление о Dependency Injection.

Использование паттернов не дает гарантии, что ваш код будет написан правильно.

Первичные правила и договоренности по именованию

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

Не устаю повторять фразу «всё уже придумано за нас», повторю ее и в данном контексте. В мире разработки уже существуют договоренности об именовании, например от компания Microsoft или те, другой вариант в Wikipedia. За основу для своих правил я взял договоренности от Microsoft. Итак, начнем.

Правила именования пространства имен для проекто компании:

✓ Название любого проекта должно начинаться с <CompanyName>. Данное правило актуально для разработчиков компании .

✓ После первого слова <CompanyName> через точку должно быть указано имя проекта.

✓ За названием проекта обязательно должна следовать название платформы.

✓ После указанной платформы части внутренней архитектуры проекта.

X Запрещается использовать знаки подчеркивания, дефисы и другие символы.

X Запрещается использовать сокращения и общеизвестные аббревиатуры

X Запрещается использовать цифры в именованиях.

X Рекомендуется избегать использования сложно составных названий в указанных частях именования

Правила именования переменных:

✓ Используйте легко читаемые имена идентификаторов. Например, свойство с именем HorizontalAlignment является более понятным, чем AlignmentHorizontal.

✓ Читабельность важнее краткости. Имя свойства CanScrollHorizontally лучше, чем ScrollableX (непрозрачными ссылка на ось x).

X Запрещается использовать знаки подчеркивания, дефисы и другие символы.

X Запрещается использовать венгерскую нотацию.

X ИЗБЕГАЙТЕ использования имен идентификаторов, конфликтующих с ключевыми словами широко используемых языков программирования.

X Не используйте аббревиатуры или сокращения как часть имени идентификатора. Например, используйте GetWindow вместо GetWin.

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

✓ Используйте семантически значимые имена вместо зарезервированных слов языка для имен типов. Например GetLength является именем лучше, чем GetInt.

✓ Используйте имя универсального типа CLR, а не имя конкретного языка, в редких случаях, когда идентификатор не имеет семантического значения за пределами своего типа. Например, преобразование в метод Int64 должен быть назван ToInt64, а не ToLong (поскольку Int64 — это имя среды CLR для C#-псевдоним long). В следующей таблице представлены некоторые базовые типы данных с помощью имен типов среды CLR (а также соответствующие имена типов для C#, Visual Basic и C++).

✓ Используйте обычные имена, таких как value или item, вместо того чтобы повторение имени типа в редких случаях, когда идентификатор не имеет семантического значения и тип параметра не имеет значения.

Примеры, которые не стоит использовать при именовании пространства имен:

Примеры именования пространства имен и проектов:

Для примера именованя решения возмем несуществующий сайт http://project.company.ru. Проект портала на платформе ASP.NET MVC должен иметь следующие пространство имен.

Название решения (solution):

Названия проектов (projects) по типу принадлежности к уровню абстракции:

Ссылка на основную публикацию
Adblock
detector