Членство в .NET с шаблоном репозитория

Question

Моя команда находится в процессе разработки модели предметной области, которая скроет различные источники данных за абстракцией унифицированного репозитория.Одной из основных движущих сил такого подхода является очень высокая вероятность того, что эти источники данных претерпят значительные изменения в ближайшем будущем, и мы не хотим переписывать бизнес-логику, когда это произойдет.Одним из источников данных будет наша база данных участников, которая изначально была реализована с использованием поставщика членства по умолчанию ASP.Net.Поставщик членства привязан к пространству имен System.Web.Security, но у нас есть руководство по проектированию, требующее, чтобы наш уровень модели домена не зависел от System.Веб (или любая другая зависимость от реализации / среды), поскольку он будет использоваться в разных средах, и мы не хотим, чтобы наши веб-сайты напрямую взаимодействовали с базами данных.

Я рассматриваю, какой был бы хороший подход к согласованию подхода MembershipProvider с нашей абстрагированной n-уровневой архитектурой.Мое первоначальное ощущение заключается в том, что мы могли бы создать "DomainMembershipProvider", который взаимодействует с моделью домена, а затем реализовать объекты в модели, которые имеют дело с репозиторием и обрабатывают проверку / бизнес-логику.Затем репозиторий реализовал бы доступ к данным с помощью нашего (пока еще не определенного) инструмента ORM / data access.

Есть ли какие-либо явные пробелы в этом подходе - я не работал тесно с классом MembershipProvider, поэтому вполне может чего-то не хватать.В качестве альтернативы, существует ли подход, который, по вашему мнению, лучше удовлетворит требованиям, которые я описал выше?

Заранее благодарю за ваши мысли и советы.

С уважением, Зак

Answer 1

Прошло 6 месяцев с тех пор, как был задан этот вопрос, и, похоже, никто не смог дать ответ, поэтому я подумал, что объясню решение, которое мы в конечном итоге выбрали.

По сути, мы решили не использовать какую-либо реализацию MembershipProvider - вместо этого мы используем нашу собственную пользовательскую службу членства, расположенную поверх репозитория.Для нас было важно поддерживать существующую базу данных aspnet_Membership, поэтому наш репозиторий в основном продублировал встроенную функциональность SqlMembershipProvider (по крайней мере, те аспекты, которые нам нужны) - изначально через Linq-to-SQL, но теперь мы переходим на NHibernate.Планируется заменить базу данных участников примерно через год, когда все наши веб-сайты будут обновлены для использования новой модели.

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

В конечном счете, мы считаем, что, хотя поставщик членства является мощным и простым в использовании инструментом в рамках ASP.Net, если он не соответствует более широкому подходу, используемому в вашем приложении, стоит рассмотреть альтернативный подход.

Answer 2

Интересно, спасибо, что опубликовали свое окончательное решение.Я нахожусь в аналогичной ситуации, но пишу пользовательский Membershipprovider.Я не знаю, куда поместить провайдера, потому что ему нужен доступ как к базе данных, так и к системе.Веб-пространство имен.Похоже, что это единственный класс, который нарушает весь этот дизайн разделения задач.