2012-11-30 44 views
6

Cách được đề xuất để truy xuất danh sách tất cả Tài nguyên mà Người dùng có quyền truy cập là gì? Trong nhiều ví dụ tôi đã thấy, Ủy quyền được đặt vào một dịch vụ riêng biệt - thường là một phương pháp cho thấy một phương thức tương tự như isAuthorized(), có thể được sử dụng cho các truy vấn riêng lẻ ("Người dùng có được phép sử dụng Tài nguyên ABC hay không?" ? ") cũng như truy vấn hàng loạt (" Người dùng có được phép sử dụng bất kỳ danh sách tài nguyên nào sau đây không? ").Dịch vụ ủy quyền - trả lại danh sách tài nguyên được ủy quyền

Trong khi phép logic tồn tại trong dịch vụ ủy quyền, các thi các chính sách cấp phép được giữ bên trong ứng dụng riêng của mình (ví dụ, lớp kinh doanh logic cho thực sự thực hiện quyền truy cập vào tài nguyên, dựa trên kết quả từ dịch vụ Ủy quyền hoặc lớp trình bày để hiển thị/ẩn các tùy chọn riêng lẻ dựa trên kết quả từ Dịch vụ cấp phép, v.v.).

Cách ưa thích để làm điều này nếu, ví dụ, lớp Truy cập dữ liệu của tôi có tiềm năng hàng tỷ "tài nguyên" mà nó có thể trả lại? Lớp logic nghiệp vụ của tôi có truy vấn tất cả dữ liệu đó (chuyển tất cả dữ liệu đó qua mạng) và sau đó chuyển tiếp danh sách khổng lồ đó tới Dịch vụ cấp phép (một lần nữa qua mạng), chỉ để có danh sách khổng lồ "ALLOW/DENY" được gửi trở lại logic kinh doanh? Rõ ràng điều đó không có vẻ đúng.

Đây có phải là trường hợp chúng tôi không thể tách "truy cập dữ liệu", ủy quyền logic và logic nghiệp vụ không? Thay vào đó, tôi có thể yêu cầu lớp Truy cập dữ liệu của mình chỉ trả lại cho tôi danh sách tất cả các Tài nguyên mà Người dùng có quyền truy cập, có thể được thực hiện dưới dạng tham gia cơ sở dữ liệu đơn giản hay không. có quyền truy cập vào tài nguyên nào dưới các điều kiện (tức là chính sách ủy quyền) được nhúng trong mã truy cập dữ liệu và do đó, các chính sách đó sẽ được trải qua cơ sở mã của tôi (ví dụ: một số logic ủy quyền sẽ có trong Truy cập dữ liệu của tôi Lớp, một số sẽ nằm trong Lớp ủy quyền của tôi, v.v.)?

Có thể hiệu suất vượt trội so với kiến ​​trúc "sạch", nhưng có cách nào tốt hơn để thực hiện việc này không?

+0

Tôi đang đối mặt với một câu hỏi hóc búa tương tự với ứng dụng cũ lớn mà tôi đang làm việc. Kịch bản "tập hợp kết quả lớn" là khó khăn, và tôi chắc chắn không nghĩ rằng đó là một vấn đề không giống như sJhonny ngụ ý. Trong khi tập hợp kết quả của tất cả ** bản ghi ** có thể không phải là thiết kế tốt, bạn vẫn gặp sự cố nếu bạn muốn cung cấp số lượng bản ghi hoặc số trang (và thiết kế tốt * sẽ *). Điều này càng trở nên khó khăn hơn nếu lớp dữ liệu của bạn được xây dựng trên một công nghệ khác, ví dụ, các thủ tục lưu sẵn SQL. Ngay cả khi bạn thừa nhận sao chép logic ủy quyền của mình, nó vẫn ở một ngôn ngữ khác! – Snixtor

Trả lời

0

Tôi không có một câu trả lời dứt khoát cho câu hỏi của bạn, nhưng tôi có thể cung cấp một số pointers-

  • bạn hỏi

    Liệu truy vấn lớp kinh doanh logic của tôi tất cả dữ liệu đó và sau đó chuyển tiếp danh sách khổng lồ đó vào Dịch vụ cấp phép, chỉ để có được danh sách "ALLOW/DENY" khổng lồ được gửi lại cho logic nghiệp vụ?

Vâng, điều đó dường như không thực sự giống với kịch bản của tôi. Bạn có thể nghĩ đến một tình huống mà bạn muốn trình bày tất cả các bản ghi có sẵn cho người dùng không? Không hợp lý hơn nếu bạn muốn lọc thêm các bản ghi đó (ví dụ theo loại, ngày, v.v.), và có thể bạn cũng muốn trang chúng để người dùng có được tập kết quả kích thước cắn.

  • Thêm vào đó thực tế là rất có thể bạn chỉ muốn được đi định hồ sơ đến và đi từ dịch vụ của bạn, bạn có thể thấy rằng phương pháp này là doable cho bạn.

  • Cũng lưu ý rằng việc có logic ủy quyền của bạn là 'dịch vụ' không nhất thiết có nghĩa là nó phải nằm trên một máy khác; bạn có thể thực hiện nó như là một mô đun logic riêng biệt, và vẫn chạy nó trên cùng một máy (có thể trên cùng một tiến trình như ứng dụng của bạn, nếu bạn muốn), do đó tránh được vấn đề lưu lượng mạng.

  • quan sát của bạn rằng việc triển khai ủy quyền như một phần của truy cập dữ liệu có thể phức tạp. Tuy nhiên, có một số công cụ cơ sở hạ tầng giúp bạn với điều đó. Ví dụ: oracle's virtual private database, (n)hibernate filters và tôi chắc chắn có những người khác.

Một lần nữa, đây không phải là câu trả lời đầy đủ, nhưng chúng có thể đưa bạn đến giải pháp phù hợp với bạn.
Tôi khuyên bạn nên sử dụng 'khung ủy quyền' của google + [ngôn ngữ lập trình yêu thích của bạn] '; Tôi chắc chắn rằng ai đó đã thực hiện nó trước đây :)

0

Tôi có ý tưởng về phôi thai, không dựa trên bất kỳ trải nghiệm thực tế nào nhưng ngay từ cái nhìn đầu tiên thì điều đó là hợp lý.

Tại sao chúng tôi có dịch vụ Ủy quyền? Yêu cầu của tôi là chúng tôi có một số tính năng của dịch vụ đó vì nguồn dữ liệu của chúng tôi không hoàn thành công việc. Nếu chúng ta chỉ sử dụng một cơ sở dữ liệu RDBMS như là nguồn dữ liệu của chúng ta thì cơ sở dữ liệu có thể cảnh sát các thể loại chính. Chúng tôi có thể làm việc với Chế độ xem và cấp đặc quyền để truy cập vào các Chế độ xem đó và do đó bảo vệ Bảng và Cột như chúng tôi mong muốn. Sau đó, vẫn là tập hợp các quy tắc thuộc loại này

Thông tin về tiền lương cho nhân viên có thể được hiển thị). nhân viên, b). người quản lý và người quản lý dòng thứ hai của họ, c). thành viên của đội ngũ nhân sự thù lao.

Tôi tin rằng những quy tắc uỷ quyền như vậy có ngữ nghĩa kinh doanh, và được thực hiện tốt nhất bởi một dịch vụ ủy quyền và sự biểu hiện của dịch vụ đó là trong điều kiện của các đối tượng kinh doanh:

can This employee see That employee's salary? 

Nó không phải được thể hiện trong thuật ngữ của bảng, hàng và cột nhưng ở mức độ chi tiết hơn, kinh doanh trung bình hơn. Việc thực hiện điều này đòi hỏi phải xây dựng một mô hình dữ liệu thể hiện các quy tắc ủy quyền và nghiêm túc nói đây là logic nghiệp vụ, chúng tôi chỉ chọn để cấu trúc lại dịch vụ ủy quyền để đóng gói việc triển khai.

Tương phản điều này với ủy quyền Thực thể chi tiết, được thể hiện dưới dạng Chế độ xem, Bảng và Cột. Xác nhận quyền sở hữu của tôi là thuộc tính này nằm trong Nguồn dữ liệu và nếu nguồn dữ liệu của chúng tôi không thể hoặc không triển khai, thì chúng tôi cần triển khai nó trong lớp Truy cập dữ liệu của chúng tôi. Các DAO "biết" các khung nhìn/bảng mà chúng sử dụng và có lẽ cũng biết id thay mặt cho người mà yêu cầu đang được chạy và do đó quyết định có cho phép truy cập hay không.

Nói một cách lỏng lẻo: DAO có SQL để biết các thực thể, vì vậy có thể quyết định. (Có, có thể không có SQL cho một số kết thúc, nhưng DAO là đối tượng hiểu những gì đang được truy xuất.) Nó có thể được làm giàu bằng một phương thức để liệt kê các phương thức truy cập của nó được phép cho một người dùng cụ thể.

CustomerDAO.whatIsAuthorised("joeCoder") => READ, QUERY 

CustomerDAO.whatIsAuthorised("phb") => READ, QUERY, UPDATE 
1

Xác thực là tốt hơn để được bên ngoài. Ủy quyền thường quá phụ thuộc vào ứng dụng để từ hóa. Nó có thể làm việc cho các hệ thống nhỏ. Nhưng đối với các hệ thống lớn, bạn sẽ gặp phải vấn đề về quy mô như bạn mong đợi.

Một điều khác đang trả về các tập dữ liệu khổng lồ. Dường như với tôi, rằng điều này được đặt tốt hơn trong báo cáo. Vì vậy, tách các mô-đun quá trình đầu tiên từ các mô-đun báo cáo, có các yêu cầu khác nhau bởi vì trong một quy trình nghiệp vụ, bạn cần tập trung dữ liệu và báo cáo khối lượng dữ liệu và trừu tượng hóa.

Uỷ quyền KHÔNG phải là một lớp. Đó là một khía cạnh. Một ứng dụng có thể không hoạt động mà không có một lớp nếu bạn không thay thế nó ít nhất bằng một mô hình thích hợp. Nhưng nếu bạn loại bỏ các khía cạnh, bạn không nên gặp sự cố khi chạy ứng dụng. Có lẽ chương trình của bạn sẽ không đăng nhập bất cứ thứ gì hoặc bạn sẽ có thể xem nhiều dữ liệu hơn bạn được phép xem nhưng nó vẫn hoạt động.

Vì vậy, ủy quyền nên được bên ngoài từ miền ứng dụng? Không. Nó có nên tách rời khỏi logic kinh doanh không? Vâng. Cơ chế thích hợp: Các khía cạnh (AspectJ, Proxy-Pattern, Template-Class-Pattern). Đây là đề nghị chung của tôi.

Đề xuất đặc biệt cho "dữ liệu khổng lồ" trong quy trình nghiệp vụ là: Cố gắng phân vùng mô hình miền của bạn đúng cách để có ít dữ liệu tập trung (Chủ đề "Khả năng sử dụng" hoặc "Trải nghiệm người dùng"). Sau đó quay lại đề xuất chung của tôi.

Nếu bạn phải đối phó với số lượng lớn dữ liệu trong quy trình kinh doanh: Sử dụng điểm cuối cùng của "Làm cho nó hoạt động làm cho nó đúng làm cho nó nhanh". Hãy suy nghĩ về nó như là một tối ưu hóa cho các yêu cầu dữ liệu đặc biệt, được hoặc dự kiến ​​sẽ được làm chậm. Trong trường hợp này sử dụng các truy vấn sql đặc biệt, tải trước, lưu bộ nhớ đệm, vv Lớp DAO có thể là vị trí thích hợp, một khía cạnh bộ nhớ đệm hoặc một khía cạnh tối ưu hóa cho DAO-Lớp ghi đè các tác vụ thực hiện chậm. Nhanh.

Các đề xuất tôi đã đưa ra đề cập đến các trường hợp sử dụng kinh doanh bình thường. Tôi không nói về dữ liệu hay báo cáo lớn. Như tôi đã đề cập, các lĩnh vực này có những yêu cầu khác nhau.

Các vấn đề liên quan