3 уровня архитектуры

Question

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

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

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

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

Answer 1

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

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

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

Answer 2

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

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

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

public static Employee Load(int id)

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

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

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

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