Блог

Я делаю 3-уровневое приложение, используя asp.net мы с mvc хотим сделать все в соответствии с рекомендациями.

Итак, я сделал MvcSample.Bll для бизнес-логики, MvcSample.Data для данных и MvcSample.Web для веб-сайта.

У Data меня есть мой edmx файл (я использую подход, ориентированный на базу данных) и мои репозитории. И в Bll я делаю сервисы, которые будут вызываться в Web.

Итак, мой вопрос таков: должен ли я писать другие модели в Bll или использовать те, которые сгенерированы в файле edmx?

Это сильно зависит от типа проблемы, которую пытается решить ваше приложение.

По моему опыту, очень редко бизнес-логика возвращает объекты модели непосредственно из Entity Framework. Кроме того, принятие их в качестве аргументов может быть не лучшей идеей.

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

В целом, если ваше приложение является быстрым прототипом, подтверждением концепции или простым программным обеспечением CRUD, может быть достаточно использовать классы моделей EF. Однако с практической точки зрения рассмотрим индивидуальные классы бизнес-логической модели / dto.

С моей точки зрения, вам нужна другая модель для вашей Bll .

Это полностью инкапсулировало бы ваши Bll .

Я думаю, что на ваш вопрос нет правильного или неправильного ответа.

По моему опыту, я использовал обе. Давайте посмотрим на приведенный ниже пример:

У меня есть User таблица

  public class User
 {
     public int Id{get;set;}
     public string First_Name{get;set;}
     public string Last_Name{get;set;}
     public int Age{get;set;}
     public string Password{get;set;} //let's use this for demonstration 
 }
  

У меня есть вызов метода DisplayAll() в Bll . Этот метод должен вывести список всех пользователей в моей базе данных по полным именам (FirstName LastName) и их возрасту.
Я не должен возвращать User класс, потому что это приведет к раскрытию пароля, а скорее я создаю новый класс UserDto

 public class UserDto
{
    public string FullName{get;set;}
    public int Age{get;set;}
}
  

Итак, вот мой DisplayAll() :

 public List<UserDto> DisplayAll()
{
    List<UserDto> result = ctx.User  //my DbContext
                  .Select(x => new UserDto()
                  {
                  FullName = x.First_Name   " "  Last_Name,
                  Age = x.Age
                  }
    return resu<
}
  

Итак, как вы можете видеть, мой метод DisplayAll() использует как User , так и UserDto

Мой подход будет заключаться в

 MvcSample.Data
 -- Model Classes 
 -- EDMX attach to model
MvcSample.Bll
 -- Model Inheriting MvcSample.Data.Model
 -- Business Logic Class - Using MvcSample.Bll.Model
MvcSample.Web
 -- Controller using  MvcSample.Bll.Model
  

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

Вы можете использовать 3-уровневую архитектуру в asp.net таким образом

• MvcSample.BLL — уровень бизнес-логики
• MvcSample.DAL — Уровень доступа к данным
• MvcSample.Domain — Уровень домена
• MvcSample.web — веб-сайт

Все ваши классы репозитория включены в .BLL layer.Это означает, что ваша логика хранится здесь. Обычно .DAL используется для хранения .edmx классов. .Domain используется для воссоздания объектов базы данных, которые полезны для серверной части.Это означает, что если вы передаете json объект от клиента к серверу, то этот объект должен быть создан на стороне сервера.Таким образом, эти классы могут быть реализованы в .domain