Entity Framework Các thực thể POCO trong ứng dụng web đa lớp

Question

Tôi mới tham gia EF4 và chưa từng có kinh nghiệm với nó trước đây. Vì vậy, trần với tôi nếu đây là câu hỏi rất đơn giản. Tôi có các thực thể POCO (tệp .tt) trong BOL, tệp .edmx (EDM) trong DAL và ứng dụng web của tôi trong lớp Trình bày. Tất cả logic nghiệp vụ đều chuyển sang lớp BLL. Sau đây là các tài liệu tham khảo:

UI -> BLL-Dal-BOL
BLL -> Dal-BOL
Dal -> BOL
BOL -> Không ai trong số dự án của tôi.

1- Sự hiểu biết của tôi về phân biệt lớp có đúng không? Tôi có đúng hướng không? 2 - Làm thế nào tôi có thể sử dụng nhà cung cấp thành viên ASP.NET với các thực thể. Tôi có nên thực hiện thành viên, kiên trì không biết gì quá và bản đồ tất cả các bảng người dùng trong máy chủ sql cho các thực thể?

2- Làm cách nào để thêm xác thực tùy chỉnh? Tôi không có nghĩa là maxlength hoặc email hợp lệ ..., tôi có nghĩa là một cái gì đó như cấp độ truy cập. Ví dụ: tôi muốn một số người dùng nhất định có thể sửa đổi một trường (nói productprice) trong trang web của tôi. Tôi nên sử dụng phương pháp User.IsInRole ở đâu? BLL không có tham chiếu đến thông tin người dùng. sao tôi nên chuyển một số tham số cho BLL (như "bool CanChangePrice") để làm rõ các cấp truy cập?

Answer 1

Wow Kamyar, chỉ là một vài câu hỏi được bao bọc trong phần này ;-) Tôi không chắc chắn liệu tôi có đề cập đến tất cả các nền tảng có thể không, nhưng ở đây đi.

ProjectStructure
- nói chung là cấu trúc lại các dự án là đúng, và tài liệu tham khảo bạn có là chính xác. Một số người có thể lập luận rằng bạn muốn tách mối quan tâm của bạn một chút và phá vỡ một số tài liệu tham khảo, nhưng cá nhân tôi thấy cấu trúc của bạn hoàn toàn khả thi.

• Thực tế là tôi có xu hướng giữ EDXM và POCO trong cùng một dự án. Tôi chỉ có một thư mục Entities chứa EDXM và Model.Context.tt, một thư mục POCO cho Model.tt và POCO ảo của tôi (bên dưới), và một thư mục Repository cho kho lưu trữ của tôi & đơn vị công việc.

• Tôi cũng tạo một tệp có tên là VirtualPOCOs phù thủy là một lớp học ràng buộc với POCO được tạo bởi T4 của bạn. Thiết kế của tôi có xu hướng khá ràng buộc với cấu trúc cơ sở dữ liệu. VirtualPOCO cung cấp cho tôi một chút linh hoạt để đi chệch khỏi thiết kế DB trong bối cảnh tình huống một lần. Không phải đi nhiều ở đây, chỉ cần vài nhu cầu rất cụ thể mà mọi dự án dường như có.

• Bạn cũng có thể muốn xem xét một kho lưu trữ, cổng dữ liệu bảng hoặc thiết lập bản ghi hoạt động. Tất cả các mẫu này sẽ có khả năng kết hợp với một Đơn vị công việc. Có rất nhiều mẫu thiết kế và nhu cầu hoặc sở thích của bạn có thể đẩy bạn đến một hoặc khác. Điểm ở đây là để che chắn các lớp trên truy cập trực tiếp vào bối cảnh EF4. Bằng cách này bạn có thể tập trung kết nối & quản lý giao dịch và đảm bảo các lớp trên chỉ sử dụng POCO và không vô tình giữ các đối tượng linq-to-sql.

Provider Membership
Có một chắc chắn là một ly giáo giữa MembershipProvider và EF. Tuy nhiên, bạn có thể tải xuống mã nguồn cho SQLMembershipProvider và chuyển đổi nó sang sử dụng EF. Tôi thực sự đã thực hiện chuyển đổi này. Tệp dài khoảng 1500 dòng nhưng không có số lượng lớn mã ADO.

Điều bạn không hỏi, nhưng tôi nghĩ tôi nên giải quyết, liệu bạn có muốn sử dụng nhà cung cấp thành viên không. Nếu bạn đang làm quản lý thành viên cơ bản và vai trò thì nhà cung cấp thành viên, vai trò và hồ sơ có thể giúp bạn tiết kiệm rất nhiều thời gian. Để có một chuyến tham quan chuyên sâu về các khả năng, hãy xem chuỗi video tại 4GuysFromRolla (http://www.4guysfromrolla.com/articles/120705-1.aspx).

Nếu nhu cầu của bạn phức tạp hơn thì IMHO, nhà cung cấp tư cách thành viên bị hỏng khá nhanh. Ví dụ: khi người dùng đăng ký cho trang web của bạn, bạn ngay lập tức phải tạo hàng trong một số bảng khác nhau. Vâng, các nhà cung cấp thành viên được đăng ký thông qua webconfig và sử dụng giao diện nhà cung cấp thành viên. Nó chỉ chấp nhận các trường nhất định trong hàm tạo. Vì vậy, một cậu bé để làm gì? Vâng, bạn có thể mở một giao dịch quy mô lớn hơn trong bộ điều khiển của bạn, chạy các nhà cung cấp thành viên thêm chức năng người dùng, chạy MyCustomUserStuff() của riêng bạn, sau đó cam kết giao dịch. Hai lý do tôi thấy điều này không hấp dẫn là bây giờ tôi đã có mã giao dịch ngấm đường lên ngăn xếp cuộc gọi của tôi và nếu tất cả tôi cần làm là thêm một vài trường bổ sung tôi đã tăng gấp đôi các cuộc gọi cơ sở dữ liệu của tôi không cần thiết.

Tôi đoán mình vừa tìm được nhà cung cấp thành viên khá hạn chế, và một khi đã vào đó và làm nhà cung cấp tư cách thành viên tùy chỉnh của riêng tôi, lợi ích của việc sử dụng mô hình MS nhanh chóng giảm đi.

Xác thực
Tôi nghĩ câu trả lời ở đây là một điều đáng tiếc - phụ thuộc. Quyền của bạn có khá tĩnh không? tức là những người trong nhóm "SiteManagers" có thể chỉnh sửa trên toàn bộ trang web? Hoặc là các quyền của bạn tốt hơn nhiều? Có nghĩa là người quản lý trang web có quyền truy cập vào 75 trường này trải rộng trên 22 bảng này, hoặc có nhiều bảng hơn không? Ngoài ra, các quyền đó có thể thay đổi như thế nào? Quản trị viên trang web của bạn có cần phải thường xuyên bật/tắt quyền truy cập hoặc tắt các trường khác nhau trong các bảng khác nhau không?

Tôi nghĩ rằng tôi cần nghe thêm về các yêu cầu của bạn cho một câu trả lời cụ thể. Xin lưu ý rằng bạn càng có nhiều quyền hạn để tạo quyền truy cập của bạn thì phần đầu cấu hình càng đau thì khách hàng sẽ hiểu được & quản lý tất cả các quyền.

Ngoài ra, bạn đang sử dụng back-end nào? Nhiều DBA phải đối mặt với những quyết định này. Một chiến lược thường được sử dụng trong thế giới đó là tạo ra một loạt lượt xem trong đó mỗi chế độ xem hiển thị các cột mà người dùng có. Ví dụ: chế độ xem EmployeesHR sẽ chỉ hiển thị những cột mà mọi người có quyền truy cập và EmployeeDirectory sẽ hiển thị các trường mà thư mục có quyền truy cập. Sau đó, người dùng HR được cấp quyền cho chế độ xem nhân sự chứ không phải bảng bên dưới. Chỉ là một ý nghĩ.

Dù sao, hy vọng điều này sẽ hữu ích.

Answer 2

1- Sự khác biệt của bạn về các lớp có vẻ chính xác với tôi. Tôi sẽ không tham khảo DAL trong giao diện người dùng, như trong các dự án của tôi, tôi thích rằng chỉ có lớp trung lưu truy cập DAL. Nhưng nó không sai. Vì vậy, bạn có vẻ đúng hướng.

2- Theo hiểu biết của tôi, không có MembershipProvider hoạt động với EF.
Vì vậy, trong các dự án mà chúng tôi sử dụng thành viên, đây là những gì chúng tôi đã làm:

• tạo các bảng với aspnet_regsql.exe
• cấu hình các Web.Config sử dụng SqlMembershiptProvider
• thêm trong web.config KHÁC chuỗi kết nối (một cho thành viên và một cho EF)
• Xây dựng tệp EDMX với tất cả các bảng, bao gồm cả các bảng thành viên.

Trong mã, một UserManager/RoleManager (BLL hoặc Dal nó phụ thuộc vào kiến ​​trúc của bạn) có được các thông tin bằng các phương pháp Membership chuẩn. Và luôn luôn sử dụng các đối tượng thành viên, không phải các đối tượng EF. Vì vậy, trên thực tế, phần quản lý người dùng/vai trò được tách ra khỏi EF.

Chúng tôi chỉ sử dụng các đối tượng EF aspnet_* khi có liên kết giữa bảng tùy chỉnh và bảng thành viên (ví dụ: khi bạn muốn liên kết một trong bảng với bảng aspnet_Users để giữ tham chiếu về người dùng đã chèn một dữ liệu). 3- Để quản lý phù hợp, tôi sẽ sử dụng BLL RightManager để cho phép UI biết liệu người dùng có thể thay đổi trường (để bạn có thể vô hiệu hóa hoặc ngăn đầu vào) và sử dụng thông tin này trong phương pháp xác thực.
Trong dự án của tôi, tôi sử dụng bảng Right và tôi liên kết Quyền với Vai trò.Trong số RightManager, hãy cung cấp phương thức RequestRight(Right).
Nếu quyền quản lý của bạn quá đơn giản để tạo bảng, chỉ cần sử dụng User.IsInRole() trong RightManager của bạn (vì vậy tôi sẽ sử dụng nó trong BLL).
Tôi sẽ đặt phương thức xác thực trong giao diện người dùng nếu nó là "cơ bản" và trong BLL nếu nó chứa các quy tắc phức tạp hơn (liên quan đến truy cập DAL chẳng hạn).

Answer 3

về EF & Membership như tôi biết, bạn không cần phải sử dụng bất kỳ nhà cung cấp db thay vì cung cấp thành viên nhưng nếu bạn muốn, bạn có thể ánh xạ bảng thành viên trong EF và tạo phương pháp bổ sung để cung cấp dịch vụ chung