Архитектура покоя: уровень доступа к данным как модель, целью REST является вызов уровня бизнес-логики, который вызывает DAL

Question

Я использую веб-сервис SOAP в своей компании и привык к их архитектуре, которая называется Service> BLL> DAL. В настоящее время я изучаю REST и, основываясь на своих наблюдениях, думаю, что модели совпадают с DAL.

Итак, что я планирую сделать, так это то, что мои контроллеры в REST будут обходить модели и вместо этого будут вызывать BLL (и выполнять некоторую логику), который вызывает DAL. Что означает, что мои модели не будут использоваться. Это будет хорошо? Если нет, дайте несколько советов и советов.

РЕДАКТИРОВАТЬ: я не обновляю с SOAP до REST. Я просто изучаю REST и делаю отдельный проект для этого

Ниже приведен мой пример архитектуры REST:

MyProjectDAL> UserDAL

namespace DAL
{
    public class UserDAL
    {
        public class User
        {
            public int Id { get; set; }
            public string UserName { get; set; }
            public string Password { get; set; }
            public string First_Name { get; set; }
            public string Last_Name { get; set; }
            public int User_Type { get; set; }
        }


        public User User_GetRecById(string id)
        {
            string cnStr = Utilities.Common.dbConnStr;

            MySqlConnection cn = new MySqlConnection(cnStr);
            MySqlCommand cmd = new MySqlCommand();
            DataTable dt = new DataTable();
            MySqlDataAdapter adapter = new MySqlDataAdapter();

            try
            {
                cmd.CommandType = CommandType.StoredProcedure;
                cmd.CommandText = "User_GetRecById";
                cmd.Parameters.Clear();
                cmd.Parameters.AddWithValue("@p_Id", id);

                cn.Open();
                cmd.Connection = cn;
                adapter.SelectCommand = cmd;
                adapter.Fill(dt);

                var userList = Utilities.Common.ToList<User>(dt);
                return userList.FirstOrDefault();
            }
            catch (Exception ex)
            {
                throw ex;
            }
            finally
            {
                cn.Close();
                cn.Dispose();
                cmd.Dispose();
                dt.Dispose();
                adapter.Dispose();
            }
        }
    }


}

MyProjectBLL> Пользователь

namespace BLL
{
    public class User
    {
        public UserDAL.User User_GetRecById(string username, string password)
        {
            var objDAL = new UserDAL();
            var user = objDAL.User_GetRecById(username, password);
            //add more logic here
            return user;
        }
    }
}

RestService> Контроллеры> UserController

namespace RestService.Controllers
{
    public class UserController : ApiController
    {
        // GET
        public UserDAL.User Get(string user, string encryptedPW)
        {
            var objBll = new BLL.User();
            return objBll.User_GetRecById(user, encryptedPW);
        }
    }
}

Answer 1

Что касается вашего кода, я вижу ваш BLL (который я считаю доменом вашего приложения) в зависимости от DAL.Если вы измените структуру DAL в будущем, вы также будете вынуждены изменить BLL (что не является лучшим).Таким образом, быстрая победа может состоять в том, чтобы немного отделить их, добавив Dto или общие интерфейсы.Пропуск "моделей" может легко стать таким сложным в будущем.

Я также хотел бы дать вам более общее предложение.Если вы действительно хотите продвигать свои знания и у вас есть много времени и ресурсов для рефакторинга, я хотел бы предложить вам взглянуть на философию чистой архитектуры.
Моей личной отправной точкой было это видео Чистая архитектура с ASP.NET Core 2.1 , и тогда вы также можете купить книгу Роберта К. Мартина "Чистая архитектура" или взглянуть на его блог ЗДЕСЬ

Answer 2

Исправьте вопрос Прежде всего, MVC и REST - это две разные концепции.Ваш вопрос не имеет никакого отношения к концепции REST.Это связано с MVC.

---

Разница между MVC и REST: Я не перечисляю все различия в деталях, но даю базовый обзор обоих, которые могут помочь вам в данный момент,Вы можете найти n источников по обеим темам самостоятельно.

1.Отдых говорит о: Как правильно сформировать точки назначения?Как принять данные?(в теле, URL-пути или параметре URL-запроса).и т.д ....

2.MVC говорит о: Как модулировать код вашего веб-приложения?

Вы можете применить MVC к любому веб-приложению, независимо от того, какой тип архитектуры веб-службы или рекомендации (SOAP / REST) ​​использует это веб-приложение.

---

Ответьте на свойВопрос Теперь, когда мы пришли к MVC, M представляют (бизнес-логика + логика базы данных и так далее).Так что в идеале вы не должны объединять эти два в один раз.При реализации любого API, вы должны по крайней мере создать три уровня на внутреннем уровне (контроллер, бизнес-уровень, уровень базы данных).Контроллер никогда не должен напрямую взаимодействовать со слоем базы данных, для API должна быть служба прокси.
---------- MVC --------- is ----- M (бизнес-уровень + уровень данных) + V (просмотр) + C ----- (контроллер)

Пример:
Контроллер

@GetMapping(value = "myapi/Books")
public Books getBook(String bookId) {
   bookService.getBook(bookId); 
}

Сервисный или бизнес-уровень

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

 public Book getBook(String bookId) {
   bookDAL.getBook(bookId); 
 }

Уровень базы данных

public Book getBook(String bookId) {
   dbClient.getBook(bookId); 
 }