Слой бизнес-логики нуждается в собственных моделях или нет

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

Answer 3

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

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

у меня есть 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 result;
}

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

Answer 4

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

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

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

Answer 5

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

Это будет заключать в капсулу ваш Bllполностью.

Answer 6

Мой подход будет

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