Hầu hết mọi người đều sử dụng SqlMembershipProvider .NET, SqlRoleProvider và SqlProfileProvider?

Question

Hầu hết mọi người đều sử dụng SqlMembershipProvider .NET, SqlRoleProvider và SqlProfileProvider khi phát triển một trang web có khả năng thành viên?

Hoặc nhiều người tự làm cho nhà cung cấp của riêng mình hoặc thậm chí là toàn bộ hệ thống thành viên của riêng họ?

Các giới hạn của các nhà cung cấp SQL có thể khiến bạn cuộn của riêng mình là gì?

Có dễ dàng mở rộng các nhà cung cấp SQL để cung cấp chức năng bổ sung không?

Đối Reference
Per Scott Gu's Blog, Microsoft provides the source code for the SqlMembershipProvider để bạn có thể tùy chỉnh nó, thay vì bắt đầu từ đầu. Chỉ là một FYI.

Answer 1

Chúng tôi sử dụng mọi thứ ngoại trừ Nhà cung cấp Tiểu sử. Nhà cung cấp hồ sơ hoàn toàn dựa trên văn bản và thực hiện tìm kiếm văn bản đầy đủ - điều này trở nên cực kỳ chậm khi cơ sở người dùng của bạn trở nên lớn hơn. Chúng tôi đã tìm thấy nó một giải pháp tốt hơn để "vai trò của chúng tôi" phần hồ sơ của cơ sở dữ liệu api thành viên được keyed để userid trong thành viên.

Answer 2

Tôi thường sử dụng các nhà cung cấp thoát ra khỏi hộp, vấn đề chính tôi gặp phải là truy vấn trên các thuộc tính tiểu sử trên người dùng. Ví dụ: tìm tất cả người dùng có thuộc tính hồ sơ được gọi là Ô tô bằng true. Điều này là xuống đến cách chúng được lưu trữ trong cấu trúc cơ bản.

Answer 3

Về lý thuyết chúng nghe hay, nhưng không phải là cơ hội nếu bạn thực hiện bất kỳ thử nghiệm đơn vị nào mà không tạo nhiều trình bao bọc trừu tượng.

Answer 4

Nếu bạn chỉ cần hỗ trợ người dùng cơ bản (vai trò, tiểu sử, v.v.) thì nhà cung cấp mặc định sẽ hoạt động tốt.

Nếu bạn cần thêm hỗ trợ tùy chỉnh (lưu trữ dữ liệu trong cơ sở dữ liệu không được nhà cung cấp mặc định [như Oracle] hỗ trợ, nhà cung cấp trên cơ sở dữ liệu đã tồn tại, lược đồ tùy chỉnh nhiều) thì bạn nên cuộn nhà cung cấp của riêng mình.

Đối với tôi, trang web hiện tại của tôi chỉ cần hỗ trợ Vai trò cơ bản (và hỗ trợ Cấu hình tối thiểu), vì vậy tôi đã đi với nhà cung cấp mặc định.

Answer 5

Tôi đã cuộn các lớp MembershipProvider của riêng mình bằng cách sử dụng các loại MembershipUser có nguồn gốc để bao bọc lược đồ người dùng tùy chỉnh, vì vậy các thuộc tính kiểu hồ sơ hiện khả dụng ở mọi nơi như một phần của người dùng.

Answer 6

Tôi đã sử dụng SqlMembership trước đây và nó khá đẹp, trừ khi bạn cần một cái gì đó tùy chỉnh. Tôi nhớ cần một cái gì đó như firstname và lastname thông tin và tôi nhận ra không có lĩnh vực cho điều đó. Cuối cùng thay vì mở rộng, tôi đã sử dụng trường Comment của nhà cung cấp và thêm thông tin tên vào đó. Đây có lẽ là một hành vi xấu/lười/hack nhưng nó đã làm việc cho tôi trong một tình huống chật hẹp ..

Answer 7

Tôi đã sử dụng cả hai lớp tùy chỉnh và được tích hợp sẵn. Khi bạn cần truy cập cơ sở dữ liệu hoặc lược đồ khác hoặc cần phải có thêm thông tin.

Tôi đã trừu tượng hóa các lớp sao cho nó sẽ hoạt động trên lớp logic và có lớp DAL sử dụng bit data.common.dbprovider để nó hợp lý chung.