Понимание разницы между ONION и N-Layered архитектурой - PullRequest
0 голосов
/ 25 ноября 2018

Я делаю структуру приложения на основе .Net.На данный момент я использую MVC 5. Вот подробности о различных компонентах системы.
1. База данных - это базовая база данных, которая будет содержать данные
2. OData API - Этот API будет взаимодействовать с базой данных и будет выполнять только операции, связанные с базой данных (CRUD).Я хочу, чтобы этот API был единственной платформой для доступа и манипулирования данными.Это обеспечит функциональность для извлечения данных различными способами (IQueryable, SQL-запрос, хранимая процедура).
3. Бизнес-сервис - Он состоит из двух вещей.Движок и API.Механизм будет содержать бизнес-логику, которая может включать бизнес-правила, например, WorkflowEngine будет обрабатывать все действия рабочего процесса.Действие резидентного рабочего процесса (операции CRUD) и действия нерезидентного рабочего процесса (отправить, утвердить, отправить обратно).API будет взаимодействовать между UI и Engine.Затем Engine запустит бизнес-логику и свяжется с OData.BusinessAPI будут частными API, а доступ к этим API будет осуществляться по подписке (платный доступ).
4. UI - Пользовательский интерфейс будет основан на MVC и будет взаимодействовать только с Business API, и будет отвечать только за отображение данных и отправку данных обратно в BusinessAPI.


Он выглядит какN-Layed архитектура.Если я представлю интерфейсы, это будет сравнимо с архитектурой ONION.
Как я могу преобразовать его в архитектуру ONION без ущерба для безопасности , масштабируемости и производительности .Dependency Diagram Project Dependency

Ответы [ 2 ]

0 голосов
/ 26 ноября 2018

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

Это хорошая архитектура, следуя принципам SOLID :

  • каждая часть несет S единую ответственность, соберите вместе все, что меняетсяпо тем же причинам. Вы хотите изолировать свои модули от сложностей организации в целом и спроектировать свои системы таким образом, чтобы каждый модуль отвечал (отвечал) потребностям только этой одной бизнес-функции.
  • O pen Закрытый принцип: программирование для интерфейса, чтобы вы могли изменить фактическую реализацию без эффекта пульсации для клиентского модуля "

" Когда появляется новое требование,Вы можете добавить новые функции в эту систему без изменения какого-либо старого кода. Функции будут добавлены только путем написания нового кода ». Дядя Боб

  • L Принцип замещения iskov и I Принцип сегрегации по интерфейсу, это скорее способ, которым вы создаете классы, вкратце: отдавайте предпочтение композиции против iнаследование, и если компонент вашей системы интересуется только подмножеством методов класса, предоставьте этому компоненту интерфейс к классу, содержащему только подмножество методов, которые его интересуют

  • D Принцип инверсии ependency: Ваши компоненты политики высокого уровня не должны зависеть от компонентов детализации низкого уровня.Интерфейс должен определяться компонентом высокого уровня, а детали должны соответствовать ему. Например, ваш базовый уровень не должен зависеть от реализации пользовательского интерфейса, пользовательский интерфейс должен зависеть от базовых минимальных интерфейсов.

Здесь вы можете найти подробное объяснение луковой архитектуры: Виктор Рентеа - Искусство чистого кода: https://www.youtube.com/watch?v=c0L7EdsxQ_c

Схема дизайна: лукархитектура

0 голосов
/ 25 ноября 2018

Архитектура Onion - это, по сути, n-уровневая архитектура, использующая внедрение зависимостей.Например, рассмотрим приложение, которое берет несколько чисел, добавляет их и отображает результат.

N многоуровневое:

Уровень доступа к данным:

public class SqlNumbersGetter
{
    public List<int> GetNumbers() => ...
}

Уровень бизнес-логики:

public class Summer
{
    public int GetSum() => new SqlNumbersGetter().GetNumbers().Sum();
}

Уровень графического интерфейса:

public class ConsoleDisplayer
{
    public void Display() => Console.WriteLine( new Summer().GetSum());
}

Архитектура лука очень похожа, но теперь мы используем интерфейсы и внедрение зависимостей:

Уровень доступа к данным:

public interface INumbersGetter
{
     List<int> GetNumbers();
}

public class SqlNumbersGetter : INumbersGetter
{
    public List<int> GetNumbers() => ...
}

Уровень бизнес-логики:

public interface ISummer
{
    int GetSum(INumbersGetter numberGetter);
}
public class Summer : ISummer
{
    public int GetSum(INumbersGetter numberGetter) => numberGetter.GetNumbers().Sum();
}

Уровень графического интерфейса:

public interface IDisplayer
{
    public void Display(ISummer summer, INumbersGetter numberGetter)
}
public class ConsoleDisplayer : IDisplayer
{
    public void Display(ISummer summer, INumbersGetter numberGetter) => Console.WriteLine(summer.GetSum(numberGetter));
}

Тогда ваше приложение будет создавать экземпляры всех экземпляров интерфейсов и связывать их все

public void Main()
{
    new ConsoleDisplayer().Display(new Summer(), new SqlNumbersGetter());
}
...