2016-11-16 4 views
1

Проект, в котором я работаю, «Система управления университетом», и это большой. Сейчас я реализую раздел регистрации студентов, который отлично работает (небольшая часть проекта). Я использовал «Архитектура трех уровней» и «ORM - EF» в шаблоне ASP.NET MVC. В проекте мне нужно сделать некоторые проверки для регистрации студентов в зависимости от их года, отдела и т. Д. Таким образом, есть разделы, такие как DAL, BLL, наконец, контроллер и представление. Я сделал проверки в контроллере и получал данные от BLL, которые снова извлекают данные из DAL (это простое условие «Архитектура с тремя уровнями»). Поэтому я задаю следующие вопросы:Трехуровневая архитектура: получить все данные и проверки

1) Правильно ли делать проверки в контроллере?

2) Если нет и нужно сделать это в BLL, будет ли это нормально, и почему или я могу продолжать делать это в контроллере?

Примечание: Для меня выполнение валидации в контроллере или BLL кажется ОК и тем же. Это имеет какой-то эффект?

Прямо сейчас, я сделал следующее:

DAL:

public List<Student> Add(int studentID, string studentName, string email, DateTime regDate) 
{ 
    List<Student> lst = null; 
    Student aStudent = new Student(); 

    aStudent.StudentID = studentID; 
    aStudent.StudentName = studentName; 
    aStudent.Email = email; 
    aStudent.RegDate = regDate; 

    try 
    { 
     db.Students.Add(aStudent); 
     db.SaveChanges(); 
    } 

    catch (Exception ex) 
    { 
     ex.ToString(); 
    } 

    return lst; 
} 

BLL:

public List<Student> Add(int studentID, string studentName, string email, DateTime regDate) 
{ 
    return aStudentGateway.Add(studentID, studentName, email, regDate); 
} 

Контроллер:

/**Student Registration - Starts**/ 
[HttpPost] 
public ActionResult AddStudent(Student aStudent) 
{ 
    List<Department> departments = aDepartmentManager.GetAllDepartments(); 
    List<DepartmentViewModel> departmentsViewModel = aDepartmentManager.GetAllDepartmentViewModel(); 

    DateTime yearInDateTime = Convert.ToDateTime(Request.Form["RegDate"]); 
    string extractYear = yearInDateTime.ToString(); 
    var year = DateTime.Parse(extractYear).Year; 
    int department = Convert.ToInt32(Request.Form["Department"]); 

    List<Student> studentList = aStudentManager.GetAllStudents(); 

    int count = 1; 

    var query = (from c in studentList 
       where c.Department == department && c.Year == year 
       select c).ToList(); 

    foreach (var c in query) 
    { 
     if (query.Count() > 0) 
     { 
      int m = Convert.ToInt32(c.StudentID); 
      count = m + 1; //Incrementing the numbers by one with the table column 
     } 
     else 
     { 
      int m = 1; 
      count = m + 1; //Incrementing the numbers by one with the variable assigned one 
     } 
    } 

    Student student = new Student(); 
    student.StudentName = Request.Form["StudentName"]; 
    student.Email = Request.Form["Email"]; 
    student.RegDate = Convert.ToDateTime(Request.Form["RegDate"]); 
    student.StudentID = count; 

    if (aStudentManager.ExistEmailAny(student.Email)) 
    { 
     ViewBag.ErrorMessage = "Email already exists"; 
    } 
    else 
    { 
     aStudentManager.Add(aStudent.StudentID, aStudent.StudentName, aStudent.Email, aStudent.RegDate); 
     ViewBag.Message = "Registration successful. See below to verify."; 

     /**This section used to show student details after registration**/ 
     var result = (from c in departments 
         join d in departmentsViewModel on c.DepartmentID equals d.DepartmentId 
         where d.DepartmentId == department 
         select c); 

     foreach (var items in result) 
     { 
      if (count.ToString().Length > 1) 
      { 
       ViewBag.StudentID = items.Code + "-" + year + "-" + "0" + count; 
      } 
      else 
      { 
       ViewBag.StudentID = items.Code + "-" + year + "-" + "00" + count; 
      } 

      StudentViewModel.StudentID = student.StudentID; 
      StudentViewModel.StudentName = student.StudentName; 
      StudentViewModel.Email = student.Email; 
      StudentViewModel.RegDate = student.RegDate; 
     } 
     /**This section used to show student details after registration**/ 
    } 

    return View(); 
} 
/**Student Registration - Ends**/ 
+0

Благодарим вас за то, что задали этот вопрос. Я собирался задать тот же вопрос. В последнее время я работаю над различными проектами, и я всегда нахожу, что я ничего не делаю в BLL, кроме вызова DAL. Тогда для чего БЛЛ? Я также пишу все бизнес-проверки и манипуляции с объектами в контроллере. Я хотел бы знать правильный подход, чтобы сделать это. –

+0

@KrishnanduSarkar: Похоже, ваш вопрос отличается от вопроса OP, если у вас есть такой вопрос, тогда вы можете попросить нового. –

+0

Спасибо за ответы. Я попытался понять, что вы оба написали. В некоторых учебниках ** Архитектуры с тремя уровнями я видел логические части, такие как условия, которые выполняются в контроллере и на самом деле не уверены в этом. Но, несмотря на проверку данных, мне кажется, что в соответствии с требованиями проекта есть определенные условия, которые должны выполняться в контроллере, а не в DAL. Позвольте мне сделать это более ясным. В DAL мы вставляем данные. Но в некоторых случаях могут потребоваться некоторые условия для вставки этих данных. Поэтому я предполагаю, что эти условия могут быть проверены в контроллере. –

ответ

1

Я бы предоставил несколько этапов проверки в разных слоях в зависимости от контекста и значения слоя.

Во-первых, лучше всего обеспечить проверку как на стороне клиента, так и на стороне сервера.

Для стороны клиента вы должны предоставить проверки полей для обязательных полей и других простых проверок. Если вы используете MVC you can use data annotations.

Такая же проверка должна быть воспроизведена в контроллере. Здесь вам не следует быстро применять какой-то контракт к переданным параметрам. Одна хорошая практика заключается в использовании Code Contracts, которые обеспечивают предпосылки, которые должны быть удовлетворены, чтобы продолжить работу в вашем конвейере выполнения.

В бизнес-слое предусмотрена проверка, которая должна быть выполнена в бизнес-логике.

Наконец, на уровне доступа к данным обеспечьте все проверки, необходимые для сохранения ваших данных. Если вы используете EF, эффективная практика реализует IValidatableObject для ваших классов сущностей. Here в блоге Скотта Гу вы можете найти сообщение, объясняющее эту технику.

Несмотря на то, что этот подход похож на введение повторений, он обеспечит согласованность ваших данных и отдельные проблемы между вашими слоями.

+0

Итак, вы говорите, что лучше проверить данные как на стороне сервера, так и на стороне клиента. Несмотря на проверку данных, для ввода данных есть некоторые другие условия, и мне казалось, что делать это прямо в контроллере, а не в DAL. –

+0

Конечно, это ваш выбор, и это зависит от веб-приложения. Мой ответ хотел просто дать вам знать «лучшие практики» для того, что касается проверки. В любом случае я настоятельно советю выполнить проверку как на стороне клиента, так и на стороне сервера. Для части сервера вы найдете решение, наиболее подходящее для вашего варианта использования. – user449689

1

1) Правильно ли выполнять проверки в контроллере?

Нет вообще, было бы лучше использовать Data Annotation Validator Attributes и сделать валидацию в вашем классе модели.

Вторая вещь, вы делаете некоторые вещи из DAL в контроллере, как

List<Department> departments = aDepartmentManager.GetAllDepartments(); 
List<DepartmentViewModel> departmentsViewModel = aDepartmentManager.GetAllDepartmentViewModel(); 

var query = (from c in studentList 
      where c.Department == department && c.Year == year 
      select c).ToList(); 

Эти все вопросы должны быть в DAL, что точное использование DAL, чтобы взаимодействовать с базы данных и сохранить свой контроллер в чистоте.

Третья вещь,

Если передать Student к контроллеру, то не нужно, чтобы получить каждый атрибут с помощью Request.Form.

Надеюсь, что это имеет смысл!

+0

. Я использовал эти методы из BLL для проверки некоторых условий в контроллере для вставки данных @Div. –

+0

Да, это прекрасно! моя забота - просто упомянуть о хороших практиках. –

 Смежные вопросы

  • Нет связанных вопросов^_^