2016-11-25 2 views
0

В настоящее время я реорганизую некоторый код, который я написал, когда был менее опытным, и двигал логику с моего контроллера на некоторые модели, пытаясь сделать мой контроллер немного более удобочитаемым.Контроллеры C# для очистки зрения

Есть одна функция, на которую я не уверен на 100%, по которой вы отправите форму из представления после ее отправки. Код ошибки записывается в виде:

[HttpPost] 
     [ValidateAntiForgeryToken] 
     public async Task<ActionResult> NewUser(Request model) 
     { 
      if (!ModelState.IsValid) 
      { 
       return View(model); 
      } 

      Offer_Request req1 = new Offer_Request(); 
      Offer_Request req2 = new Offer_Request(); 
      req1.Request = req2.Request= model; 
      req1.offerID = 1; 
      req2.offerID = 2; 

      using (var ctx = new UserDBEntities()) 
      { 
       ctx.Request.Add(model); 
       ctx.Offer_Request.Add(req1); 
       ctx.Offer_Request.Add(req2); 
       ctx.SaveChanges(); 
      } 

      string link1 = Url.Action("EmailHandler", "Home", routeValues: null, protocol: Request.Url.Scheme); 
      string link2 = Url.Action("EmailHandler", "Home", routeValues: null, protocol: Request.Url.Scheme); 
      link1 = link1 + "?id=" + req1.ID.ToString(); 
      link2 = link2 + "?id=" + req2.ID.ToString(); 
      var body = "<p>New request from {0} at {1}</p><p>Please choose from the following</p><br><p>One day access token:</p><p>{2}</p><br><p>5 day access token</p><p>{3}</p>"; 
      var subject = "{0} wants to connect!"; 
      var message = new MailMessage(); 
      message.To.Add(new MailAddress(model.SponsorEmail)); 
      message.From = new MailAddress(##########); 
      message.Subject = string.Format(subject, model.FirstName); 
      message.Body = string.Format(body, model.FirstName, model.Email, link1, link2); 
      message.IsBodyHtml = true; 

      using (var smtp = new SmtpClient()) 
      { 
       var credential = new NetworkCredential("########", "##########"); 
       smtp.Credentials = credential; 
       smtp.Host = "smtp.office365.com"; 
       smtp.Port = 587; 
       smtp.EnableSsl = true; 
       await smtp.SendMailAsync(message); 
      } 

      return RedirectToAction("Sent"); 
     } 

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

+1

Это не должно быть в вашей модели. Либо реорганизуйте код в частный метод в контроллере, либо, лучше, создайте отдельную службу, которая является вызывающим методом контроллера. –

+0

@ StephenMuecke Привет за ответ! В настоящее время я создаю классы в папке «models», которые вызывается моим контроллером для запуска их различных методов. Я не совсем уверен, что это означает, что эти модели в отдельную службу означают создание нового файла в моем решении (т. Е. Перемещение классов из моделей в каталог решений)? –

+1

Нет, модели не входят в отдельную службу - метод отправки электронной почты - класс, который содержит метод, скажем, 'SendEmail (...)' (и этот класс будет реализовывать интерфейс, чтобы вы могли вставьте его в контроллер с помощью DI. –

ответ

1

Выдача учетных данных всегда будет более безопасной, когда приложение опубликовано, когда они затем будут обернуты в DLL. DLL-файлы могут быть деконструированы и реконструированы так, чтобы не защищать код, а помогать.

Я имею тенденцию иметь три слоя для моего приложения для обеспечения безопасности и аккуратности. Сначала у меня есть DataAccess Layer в одном проекте, Business Logic в другом, и все, что делает контроллер, сводят все вместе в одном месте. Таким образом, он также отделяет пользовательский интерфейс. Я считаю, что это стандартная практика для большинства британских компаний, занимающихся разработкой программного обеспечения. Вы можете абстрагироваться дальше, если хотите, и такие места, как страховые компании и финансовые учреждения, могут иметь 20 или 30 уровней в зависимости от того, как данные должны обрабатываться повсюду, но для личных проектов я считаю, что три слоя работают нормально.

Надеюсь, что некоторые из этих бессвязных помогает!

+0

Эй, это имеет смысл в плане дизайна - однако, когда дело доходит до dataAccess и businessLogic, я не уверен, что классифицирует как тот или иной. Будет ли программа, использующая этот формат, структуру, в которой представления и контроллер представления находятся в одном проекте: чтение и запись базы данных, модели данных и требуемая конфигурация в другом; бизнес-логика (я предполагаю) будет состоять из методов составления и отправки электронных писем, создания вызовов API и управления ими ответы. С необходимой информацией, отправляемой между проектами по мере необходимости? –

+0

Как правило - Data Acess ничего не делает, кроме как управлять данными (так что тяните с сервера db и т. д.), бизнес-уровень затем манипулирует им на месте, чтобы он соответствовал тому, как вам нужно доставлять на ваш взгляд - так что все полномочия и обработка учетных данных будут на уровне данных, если вам нужно изменить его, поместить в него новый класс, добавьте к нему и т. д., что будет сделано на бизнес-уровне - тогда ваш контроллер для вашего пользовательского интерфейса (представлений) захватит все эти управляемые данные и поместит их в вашу модель в удобном для пользователя образом :) –

1

Обычно, что хранится внутри контроллера, просто запускается command из реализации interface, скажем, (метод SendEmail), что делает контроллер не зависящим от того, как отправляется почта.

Это означает, что контроллер отвечает только за подключение к модели. Поэтому логика должна идеально сидеть где-нибудь в модели или службе.

Затем эта услуга вводится в контроллер с помощью DI.