3-уровневая архитектура проблема

Question

В настоящее время я начал работать над 3-х уровневой архитектурой, но у меня есть некоторые сомнения в моем сознании.

Как правило, мы связываем управление данными с объектным источником данных и вызываем функцию бизнес-объекта для выполнения операции выбора, вставки, обновления или удаления. У меня нет никаких проблем с этим.

Но проблема в том, что у меня есть часть входа, которая содержит только 2 текстовых поля и 1 кнопку, и я создал бизнес-объект, чье свойство представляет собой имя пользователя и пароль, а затем я назвал функцию бизнес-объекта, и эта функция, в свою очередь, называется уровнем доступа к данным чтобы вернуть datarow, содержащий идентификатор пользователя из базы данных, если имя пользователя и пароль правильные ....

поэтому я считаю, что это неправильный способ работы с 3 уровнями, когда вы не работаете с элементами управления данными ... потому что здесь мы необоснованно вызываем функцию и функцию, в то время как мы можем получить доступ к данным даже в коде позади ... поэтому, пожалуйста, скажите мне, правильно ли я работаю или нет? ... или есть лучший способ выполнить аналогичную операцию.

Answer 1

ASP.NET нечетна, когда дело доходит до разделения данных и бизнес-логики. MVC упрощает работу, но вы не укажете, используете ли вы его. Мы обсуждаем этот вопрос следующим образом:

Мы строим статический класс сериализации , который несет полную ответственность за взаимодействие с базой данных. Только он отвечает за вызов хранимых процедур. Он возвращает экземпляры POCOs (простые старые объекты C#), которые сериализатор знает, как создавать экземпляры и заполнять данными из базы данных.

Теперь POCOs предоставляют методы фасада, которые пересылают вызовы в сериализатор. Например:

public static Employee Load(int id) 

вызывает метод Load в классе EmployeeSerializer. Это не сделало бы ничего другого. Но он позволяет страницам работать с объектами Employee естественным образом.

Возможно, это не так, но это лучше, чем у нас раньше. Аналогично, вы вызываете Employee.Save(), и вызов пересылается на EmployeeSerializer.

Это сохраняет все вызовы хранимой процедуры, инкапсулированные в один класс. Бизнес-логика инкапсулируется в классе Employee. И страницы могут работать с сотрудниками.

Обратите внимание, что бизнес-объекты могут жить в отдельной DLL из объектов базы данных, но это приводит к проблемам с круговыми зависимостями. Храните их в одной DLL и помещайте их в отдельные пространства имен. Но отделяйте их от страниц ASP.NET, помещая их в отдельную DLL вместе.

Answer 2

Это ленивый программист в вас.

Три уровня - это абсолютный. У вас не может быть своего рода-сорта-3-ярус. Это не 3-х уровневый.

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