2009-03-26 28 views
8

Khi phát triển giao diện của tôi (hợp đồng) và triển khai cụ thể của chúng, cả hai mô hình dữ liệu cũng như kho lưu trữ, tôi thấy mình đặt câu hỏi nơi logic hợp lệ nên đi. Một phần của tôi (có khuynh hướng thắng) nói rằng bản thân lớp phải chịu trách nhiệm cho việc xác nhận của chính nó (chuỗi dài, ngày đệm, vv), nhưng phần khác của tôi nói điều này nên được chuyển đến kho lưu trữ bởi vì khi lưu trữ lâu dài, các giá trị này có thể thay đổi dựa trên việc triển khai kho lưu trữ của bạn.Trường hợp logic hợp lệ nên được triển khai ở đâu?

Tôi nghĩ rằng có một số xác nhận phải được thực hiện ở cấp lớp và nghĩ rằng có lẽ nên được giữ lại với nhau và không thay đổi ngay cả khi kho lưu trữ, đó là lý do tại sao tôi có xu hướng giữ nó trong lớp.

Tôi là tất cả về việc đưa vào xác thực giao diện người dùng nhưng điều này là không bao giờ đủ vì có thể bỏ qua nhiều xác thực giao diện người dùng.

Tò mò những gì mọi người nghĩ và lý do đằng sau nó.

Trả lời

3

Quy tắc xác thực phải được xác định ở cấp lớp theo kiểu trừu tượng có thể cả 2) được chạy trong môi trường tự nhiên của lớp 2) được hiển thị dưới dạng quy tắc cho các môi trường phụ thuộc khác, chẳng hạn như thủ tục giao diện người dùng hoặc lưu trữ giao diện người dùng .

Điều này giúp bạn tập trung vào logic, trong lớp và xác thực phụ trợ trong giao diện người dùng và bất cứ nơi nào khác - dễ bảo trì vì nó được lấy từ lớp thay vì tách logic ở một vị trí bị ngắt kết nối. Chiến thắng toàn diện.

+0

Không có gì nếu xuất phát từ cơ sở dữ liệu. Thay vào đó ngược lại nếu người ta định lái chiếc kia. Đừng dictate hành vi người dùng từ lược đồ cơ sở dữ liệu của bạn. Ngoài ra, bạn không muốn các bài kiểm tra đơn vị lớp của bạn phụ thuộc vào các kết nối cơ sở dữ liệu và các tạo phẩm. – dkretz

0

Chắc chắn trong môi trường web, mọi thứ bạn đặt ở phía máy khách để xác thực có thể bị bỏ qua.

Nói chung tôi đặt xác thực trong lớp. Sau đó, có những người định cư tăng hoặc ném một ngoại lệ, hoặc nếu bạn thích sử dụng một giá trị trả lại. Tôi sử dụng các ngoại lệ trong thế giới .Net vì tôi có thể có một bộ ngoại lệ tùy chỉnh với các thông báo quy tắc xác thực rõ ràng được trả lại cho người tiêu dùng/khách hàng.

1

Tôi đã có rất nhiều thành công khi đặt tất cả xác thực của mình ở gần vị trí nơi dữ liệu sẽ được giữ trong lớp doanh nghiệp. Ví dụ. trong tài sản định cư. Điều này đảm bảo rằng bạn chỉ bao giờ chuyển qua dữ liệu hợp lệ trong lớp doanh nghiệp của mình và cũng đảm bảo rằng giao diện người dùng sẽ nhận được dữ liệu hợp lệ từ lớp nghiệp vụ.

Ở một mức độ nào đó, điều này cũng tránh sự cần thiết phải có nhiều xác thực trong lớp dữ liệu của bạn nếu mã của bạn luôn đi qua lớp doanh nghiệp của bạn.

Quy tắc duy nhất tôi có thể hiểu được là không bao giờ tin cậy xác thực cấp UI, vì lớp này dễ bị xâm phạm nhất (đặc biệt trong ứng dụng web). Xác thực cấp độ người dùng là một chất làm ngọt chỉ để làm cho trải nghiệm người dùng của bạn thân thiện hơn.

1

Hợp đồng (giao diện) giữa hai bên cho biết, A và B sao cho cả hai bên có nghĩa vụ nhất định. Hợp đồng nói gì? B có phải nhận dữ liệu hợp lệ không? Nếu đúng như vậy, B không nên thực hiện xác thực. Nhưng nếu A là giao diện người dùng thì sao? Rõ ràng bạn không muốn đặt xác thực ở đó. Thông thường, tốt nhất là giới thiệu một bên thứ ba, nói rằng C. A có hợp đồng với C, lần lượt có hợp đồng với B. B dự kiến ​​dữ liệu đã được xác thực. A có thể gửi crap. C thực hiện xác thực.

Nếu hợp đồng được thiết kế tốt, điều này gần như không bao giờ là vấn đề. Tiết lộ hợp đồng và đặt nghĩa vụ cho từng bên. Nếu một bên nào đó có quá nhiều nghĩa vụ thì hãy giới thiệu một bên thứ ba.

0

Xác thực phải là một phần của đối tượng. Làm cho môi trường trở thành một phần của các tham số cho hàm tạo của đối tượng. Bằng cách đó bạn có thể tùy chỉnh logic xác thực cho môi trường nhưng đối tượng không phải tìm ra nơi nó đang chạy.

Tôi luôn sử dụng xác thực giao diện người dùng mặc dù điều này là tốt nhất. Nó tiết kiệm các chuyến đi vòng đến máy chủ (băng thông không thêm lên) và nó cho phép bạn được nhiều người dùng thân thiện với các thông báo lỗi. Nhưng nó không bao giờ là lớp xác nhận duy nhất.

6

Trường hợp logic hợp lệ nên được triển khai ở đâu?

Ở mọi nơi.

  • Bạn nên xác nhận ở cấp giao diện người dùng để người dùng được ngay lập tức, thông tin phản hồi hữu ích (ví dụ, điền vào một mẫu web và bên cạnh nó có javascript nói, "mật khẩu quá ngắn", do đó bạn không nhận được các chuyến đi không cần thiết đến máy chủ)
  • Bạn nên xác thực bất kỳ đầu vào nào vào phần mềm chính từ giao diện người dùng. Không bao giờ tin tưởng giao diện người dùng, đặc biệt là trên các dự án lớn hoặc trên các trang web - chúng có thể bị bỏ qua hoặc chúng có thể được phát triển bởi một nhóm khác.
  • Bạn nên xác thực các yếu tố đầu vào cho các hàm/phương pháp/lớp học. Đây là những hạn chế vốn có mà không có gì để làm với các yêu cầu dự án (khác hơn là nó có thể quản lý phạm vi đầu vào cần thiết). Ý tưởng ở đây là khuyến khích sử dụng lại mã an toàn. Tham gia một lớp học, và bạn biết nó sẽ thất bại nếu bạn đi ra ngoài các tham số của nó - và nó sẽ cho bạn biết nếu nó làm như vậy.
  • Có một loạt các lĩnh vực khác, nơi xác nhận nên diễn ra (DB, sao lưu/khôi phục, các kênh truyền thông phụ trợ, vv)

Nó có vẻ như rất nhiều công việc, hoặc chi phí thêm, nhưng thực tế là có lý do chính đáng để xác thực lại mọi thứ trong chuỗi, ít nhất trong số đó là bắt lỗi trước khi chúng trở thành vấn đề.

-Adam

+1

Đây là câu trả lời cho câu hỏi KHI nên xác thực logic được thực hiện không ở đâu. – disklosr

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