Должен ли я создать еще один проект библиотеки классов, такой как Sigma.DataAccess, чтобы отдельно хранить поставщиков и репозитории?Это приемлемый способ сделать архитектуру решения MVC?Это всего лишь подтверждение концепции, над которой я работаю, и сам проект может стать действительно огромным.Я хочу убедиться, что я не делаю ничего глупого для начала.
Да - держите их отдельно, если ваша реализация изменится, вы окажете меньшее влияние.
IMembershipRepository и IMembershipService содержат в основном одни и те же функции, за исключением того, что IMembershipRepository возвращает данные, используя специально разработанный объект MembershipModel;тогда как IMembershipService является интерфейсом стандартного ASP.NET MembershipProvider и возвращает MembershipUser и MembershipCollection.Должен ли я иметь интерфейс IMembershipRepository, унаследованный от IMembershipService?
На самом деле в представленных примерах - фактически, кажется, нет разницы в реализации - оба метода являются bool ValidateUser (), который определенно повторяется, но потому чтоу каждого из них есть конечное использование, которое может «потенциально» изменить их абстрагирование на два отдельных интерфейса, поэтому я не хотел бы, чтобы один наследовал от другого.может использовать его против любых других приложений пользовательского интерфейса, таких как WebForms или WinForms.Возможно ли это с тем, как проект структурирован?
Да - но я бы выбил и оставил только моделей в этом проекте.Все, что не является моделью - не должно быть в этом проекте.
Кроме того, я не хочу использовать поставщика членства ASP.NET "из коробки", потому что мне нужно решениеэто может работать против существующей базы данных.Я предполагаю, что это означало бы, что мне нужно настроить функции, доступные в поставщике членства ASP.NET, для работы с моей настраиваемой базой данных.Пожалуйста, исправьте меня, если мои предположения неверны.
Это правильно - вам нужен пользовательский поставщик членства SQL