Требуется некоторое руководство по архитектуре ASP.NET MVC 3
Я опытный разработчик .NET, который в основном работает с веб-формами. Я знаком с MVC, но еще не использовал его в коммерческих целях. В настоящее время я занимаюсь самообразованием в этой области и несколько озадачен различиями во мнениях по поводу архитектуры. Позвольте мне задать этот вопрос, понимая, что нет правильного или неправильного ответа, но я просто ищу элегантное решение.
Начну с того, что я не использую фреймворк сущностей или какой-либо ORM - я хотел бы непосредственно реализовать свои собственные бизнес-объекты и код доступа к данным (используя ADO, SPROCS и т.д.), чтобы обеспечить их оптимальность, это мое личное предпочтение. Именно здесь я испытываю трудности в поиске последовательной информации, поскольку большинство информации относится к использованию LINQ to SQL или Entity Framework.
Структура моего приложения состоит из следующих проектов:
- Web (веб-приложение MVC 3)
- Models (библиотека классов)
Есть только два проекта, потому что у меня проблемы с развязкой; в этом корень моего вопроса. Моя библиотека классов моделей содержит...
- классические бизнес-объекты с полями и свойствами
- Класс хранилища для каждого бизнес-объекта, который содержит код доступа к данным (ADO.NET straight forward SqlDataReaders и т.д.)
- Интерфейс для каждого класса хранилища
Проблема, которая у меня есть, это зависимость между всеми этими слоями. Это совсем не кажется правильным!
1.Бизнес-объекты должны содержать методы, которые реализуют бизнес-логику, так что помимо полей и свойств есть методы для реализации любой необходимой логики?
2.Классы хранилища выполняют код доступа к данным, но знают о бизнес-объектах, это опять не кажется правильным, код доступа к данным должен сидеть в своей собственной библиотеке классов и ничего не знать об объектах?
3.Контроллеры (в веб-слое) используют интерфейсы хранилища, но почему? Они не должны содержать бизнес-логику, это должна делать "модель" или бизнес-объект? Контроллеры, конечно, не должны содержать бизнес-логику, так что это опять же неправильно. Мне не нужна бизнес-логика в хранилищах, поскольку они попадают в базу данных.
Я изо всех сил пытаюсь найти элегантную архитектуру для приложения, просто базовый набросок того, как реализовать мои собственные объекты, мой собственный код доступа к данным и обеспечить свободное соединение приложения. Может ли кто-нибудь подсказать мне, пожалуйста?