пользовательский поставщик членства - вот как я делал это раньше. это сработало очень хорошо. моя группа совершила ошибку, заставив службу wcf соответствовать интерфейсу поставщика членства, что было ненужным и беспорядочным. Если вы решите пойти по этому пути, я бы порекомендовал вам самостоятельно заключить контракт на обслуживание, как вы этого хотите, и внедрить у вашего провайдера эту услугу.
если бы я делал это снова, я бы вообще не использовал wcf, а просто использовал бы поставщика членства (существующий или настраиваемый, в зависимости от ваших потребностей) для приложения asp.net, которое напрямую обращается к базе данных, а чем слой wcf и имеют общую сборку, которую могут использовать другие инструменты, которые напрямую общаются с базой данных. даже имея общий код на уровне обслуживания wcf. Я не думаю, что использование сервиса действительно дает много такого, чего нельзя было бы получить, просто используя обычную сборку. поставщик членства asp.net в любом случае будет чем-то отдельным.
это предполагает, что вы находитесь в среде, где вы можете просто подключить инструменты рабочего стола к базе данных. Если это сценарий, развернутый в Интернете, вам, вероятно, нужно сделать это с помощью какой-либо службы, и wcf - отличный кандидат для этого. Тем не менее, вероятно, более короткий путь - использовать существующего поставщика членства и построить службу wcf на основе соответствующей базы данных, чем создавать поставщика членства, который использует службу wcf. я не думаю, что было бы плохим выбором сделать второе, но вам, вероятно, будет лучше с первым. Хотя это, конечно, зависит от множества факторов.
person
Dave Rael
schedule
25.11.2011
