Все еще нужен слой модели, когда есть слой бизнес-логики?

Question

в решении asp.net, что бы вы сделали с модельным проектом, когда у вас есть бизнес-проект?

В интерфейсе я считаю очень простым и эффективным использование источника данных объекта, сопоставленного с классом, который выполняет все CRUD. Я положил этот класс в сторону бизнес-проекта. Класс содержит запросы linq, которые получают и устанавливают данные из / в базу данных.

Так что же тогда остается проекту Model? интерфейс говорит с бизнес-проектом просто отлично. Что-нибудь еще или лучше можно сделать здесь?

и вот еще вопрос, что должно быть на вашем уровне доступа к данным, если вы используете Linq to SQL? только файлы DBML?

Я ценю ваше время и усилия

С наилучшими пожеланиями

Answer 1

Общепринятой практикой является использование Просмотр модели .

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

Хотя я мог бы объяснить реализацию в мучительных деталях с большим количеством примеров кода, это было бы бессмысленно, потому что Джимми Богард уже писал «Как мы делаем MVC - Просмотр моделей . У вас будет гораздо лучшее понимание» о том, как реализовать этот подход, и о причинах этого после ознакомления с этой статьей.

Answer 2

Вам не нужно НУЖНО ничего, если вы действительно этого хотите: P.Папка модели в основном используется в новых проектах MVC в качестве руководства, показывающего, как выполнить разделение задач с MVC.Если ваш бизнес-уровень уже находится в другом проекте или в другой папке, вы можете удалить его.Папка не имеет особого значения в архитектуре MVC.

Answer 3

Если вы используете ASP.NET MVC, я бы сделал следующее:

Иметь «локальную» модель, которая действует как интерфейс между BLL и контроллером. По сути, контроллер должен знать только об объектах, которые вы используете локально.

Это, вероятно, будет связано с отображением кода в «репозитории» части вашей Модели; AutoMapper - хороший пример того, что можно использовать для этого.

Для этого есть несколько причин:

1. Ваш контроллер не связан напрямую с изменениями в BLL.
2. Зависимости для тестирования. Если вы используете метод «Контроллер на один объект» для построения вашего контроллера, то у вас намного меньше зависимостей. Это становится несколько проблематично, если вы перетаскиваете эти классы и зависимости непосредственно в контроллер, потому что тогда вам придется выкручивать гораздо больше, и вы можете проваливать тесты по причинам, которые не сразу очевидны.