От ASP.NET MVC к существующему приложению ASP.NET с BusinessLayer. Можно ли загрузить объекты ViewModel из существующего BusinessLayer? - PullRequest
2 голосов
/ 22 декабря 2011

У меня есть устаревшее веб-приложение asp.net, которое имеет 2 слоя: пользовательский интерфейс и BusinessLayer.Проект пользовательского интерфейса имеет тип веб-сайта ASP.NET, а BL - библиотеку классов типов.В проекте BL есть классы для сущностей моего приложения, таких как Customer, User, Empoloyee и т. Д. Каждый класс имеет методы для чтения из базы данных и заполнения свойств объекта из DataReader. Это означает, что класс Customer содержит вместе мой объект Customer и методы доступа к данным..

Теперь я изменил веб-приложение для поддержки MVC.Старый сайт (веб-формы) работает как обычно, а новое обновление сайта, которое я делаю (добавление функций администратора для управления сайтом), находится в ASP.NET MVC3.Роутинг и все отлично работает.Но меня беспокоит структура / ремонтопригодность проекта.

Для новой части MVC мне пришлось создать ViewModels для нескольких сущностей, таких как CustomerViewModel, EmployeeViewModel.Я создал другой класс под названием "CustomerService" с такими методами, как GetCustomerViewModel, и внутри этого метода я вызываю GetCustomerMethod из существующего BusinessLayer и считываю значения свойств из объекта (типа сущности, упомянутого в существующем проекте BL) и назначаюэто к объекту CustomerViewModel (я рассмотрю некоторые образцы AutoMapper для этого позже) и верну это из этого метода.My View будет использовать этот объект для отображения данных в пользовательском интерфейсе.Причина, по которой я создал класс "CustomerService", заключается в том, что мне может потребоваться выполнить некоторые проверки условий или некоторые проверки бизнеса перед установкой значений для объекта CustomerViewModel.Я рассматриваю это как «средний уровень / уровень обслуживания», так что мои контроллеры будут тонкими.

от моего контроллера клиента

public ActionResult Details(int id)
{

   MyProject.MVCViewModel.CustomerViewModel objCustomerVM;
   objCustomerVM=MyProject.MVCMiddleLayer.CustomerService.GetCustomerViewModel(id);

   return View(objCustomerVM); 
}

в моемCustomerViewModel

 public static CustomerViewModel GetCustomerViewModel(int customerId)
    {
       //Create an object of new ViewModel
       CustomerViewModel objCustomerViewModel  = new CustomerViewModel ();

       //Get an object from Existing BL of Customer of type ExistingBL.Customer
       ExistingBL.Customer objCustOld=new Customer(customerId); 

        //Check some properties of the customer object and set values to the new ViewModel object
          if(objCustOld.Type=="normal")
          {
            objCustomerViewModel.Priority=2; 
          }
          else if(objCustOld.Type=="abnormal")
          {
            objCustomerViewModel.Priority=1;
            objCustomerViewModel.Message ="We love you";
          }
         //Some other checking like this....
    return objCustomerViewModel;
   }

Это неправильный подход?Мой код будет грязным?Я не доволен ViewModel, так как это (почти) дублированный код из моих существующих сущностей BL.Каков наилучший способ решения этого сценария.Я не уверен в использовании шаблона репозитория (который я видел в большинстве примеров) в этом случае?Должен ли я сделать это? Как это улучшить мой код?

Ответы [ 2 ]

0 голосов
/ 23 декабря 2011

Более или менее мои классы ViewModel - это переопределение свойств только с атрибутами, кто-то может поспорить, что это просто еще один служебный слой, но я делаю это по простой причине: я могу добавить надлежащие атрибуты веб-проверки, не нарушая ничего ( DataLayer должен быть доступен для других приложений).

В шортах с классом DataLayer, представляющим объект User:

public class DalUser {
  public int Id { get; set;}
  public int Age { get; set;}
  public string Name { get; set;}
  public string Surname { get; set;}

  // Business method for reading/writing/deleting

}

Моя модель представления выглядит примерно так:

public class VmUser : DalUser 
{
   [Display(Name="ID Code")]
   public override int Id { get; set; }

   [Display(Name="Age")]
   [Required]
   public override int Age { get; set; }

}

Это приводит меня к двум целям: первая - я могу использовать атрибуты, не беспокоясь о том, чтобы что-то сломать, вторая - я могу скрыть от пользователя какое-то поле, предотвратить внедрение поля (например, из FireBug - но это включает в себя определение интерфейса и используя это, а не обычные подклассы).

Это оказывается довольно полезным в моей корпоративной (мы обречены использовать EntitySpaces), и это один из менее уродливых способов, которые я нашел для частичного повторного использования сгенерированных ES классов.

0 голосов
/ 23 декабря 2011

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

  1. Поскольку единственное, что вы будете переписывать, это логика пользовательского интерфейса (View Model Object), и это прекрасно, поскольку ваши технологии пользовательского интерфейса отличаются (asp.net).против MVC)

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

public static ICustomerViewModel GetCustomerViewModel (int customerId) {// использовать DI, а не конкретную реализацию ICustomerViewModel objCustomerViewModel =new CustomerViewModel ();

   //use DI, rather than concerete implementation
   ExistingBL.ICustomer objCustOld=new Customer(customerId); 
   .
   .
   .
return objCustomerViewModel;

}

Теперь вы можете очень легко создавать фиктивные объекты с помощью любой работы над кадром.

...