#asp.net #asp.net-mvc #model #data-access-layer #business-logic
#asp.net #asp.net-mvc #Модель #уровень доступа к данным #бизнес-логика
Вопрос:
в asp.net решение, что бы вы сделали с проектом модели, когда у вас есть бизнес-проект?
В интерфейсе я нахожу очень простым и эффективным использовать objectdatasource, сопоставленный классу, который выполняет весь CRUD. Я поместил этот класс в дополнение к бизнес-проекту. Класс содержит запросы linq, которые получают и устанавливают данные из / в базу данных.
Итак, что тогда остается от проекта модели? интерфейс отлично взаимодействует с бизнес-проектом. Можно ли здесь сделать что-нибудь еще или лучше?
и вот еще вопрос, что должно быть на вашем уровне доступа к данным, если вы используете Linq to SQL? только файлы DBML?
Я ценю ваше время и усилия
С наилучшими пожеланиями
Комментарии:
1. Можете ли вы уточнить, о чем вы говорите или нет ASP.NET MVC? У вас есть оба тега; пожалуйста, отметьте, к какому из них это применимо. Вы бы не стали использовать
objectdatasourceв ASP.NET MVC.
Ответ №1:
Общепринятой наилучшей практикой является использование шаблона View Model.
Модель представления — это, по сути, сглаженное представление бизнес-объекта, которое соответствует просмотру этого бизнес-объекта в определенном контексте. Вместо передачи бизнес-объекта в представление представление визуализируется в контексте модели представления.
Хотя я мог бы объяснить реализацию в мучительных деталях с большим количеством примеров кода, это было бы бессмысленно, потому что Джимми Богард уже написал «Как мы создаем модели MVC — представления. Ознакомившись с этой статьей, вы будете гораздо лучше понимать, как реализовать этот подход, и причины для этого.
Ответ №2:
Вам ничего не НУЖНО, если вы действительно этого хотите: P. Папка model в основном помещается в новые проекты MVC в качестве руководства, чтобы показать, как разделять проблемы с MVC. Если ваш бизнес-уровень уже находится в другом проекте или в другой папке, вы можете удалить его. Папка не имеет особого значения в архитектуре MVC.
Комментарии:
1. @KallDrexx, утверждение о том, что оно не имеет «особого значения» в архитектуре MVC, неверно, как я заявляю в своем посте.
2. Я специально сказал о папке модели. Именно это я имел в виду в вопросе vauge. В противном случае я никогда не слышал, чтобы термин «уровень модели» упоминался иначе, кроме как как ссылка на бизнес-уровень
3. Папка модели имеет особое значение в ASP.NET MVC. Смотрите ссылку, если мой пост.
4. Да, извините, я пропустил эту ссылку. На самом деле я не знал об этом, и это меня немного раздражает. Я хотел бы увидеть обоснование того, что
DefaultModelBindersдолжно быть в этой папке, потому что это означает, что я должен воссоздать эту папку и работать с моей структурой папок для моих текущих проектов, из которых я ее удалил. Спасибо за ссылку!5. На самом деле я не вижу в этой ссылке ничего, что утверждает, что это должно быть в папке модели. Вы дали неправильную ссылку?
Ответ №3:
Если вы используете ASP.NET MVC, тогда я бы сделал следующее:
Имейте «локальную» модель, которая действует как интерфейс между BLL и контроллером. По сути, контроллер должен знать только об объектах, которые вы используете локально.
Это, вероятно, будет связано с отображением кода в части «репозитория» вашей модели; AutoMapper — хороший пример того, что можно использовать для этого.
Для этого есть несколько причин:
- Ваш контроллер напрямую не привязан к изменениям в BLL.
- Зависимости для тестирования. Если вы используете метод построения вашего контроллера «Один контроллер на концерн», то у вас намного меньше зависимостей. Это становится несколько затруднительным, если вы подключаете эти классы и зависимости непосредственно к контроллеру, потому что тогда вам приходится намного больше макетировать, и у вас могут быть сбои тестов по причинам, которые не сразу очевидны.