Chế độ xem không nên thực hiện xác nhận?

Tôi đã đọc " Trong mô hình MVC có nên xử lý xác nhận không? " Bởi vì tôi tò mò về việc logic xác thực sẽ đi đâu trong một trang web MVC. Một dòng trong câu trả lời hàng đầu như sau: "bộ điều khiển nên xử lý xác nhận, mô hình nên xử lý xác minh."

Tôi thích điều đó, nhưng nó khiến tôi tự hỏi tại sao chúng tôi sẽ không xác thực dữ liệu trong Chế độ xem, vì một số lý do:

1. Các khung nhìn thường có hỗ trợ xác thực mạnh mẽ (thư viện JS, thẻ HTML5)
2. Lượt xem có thể xác thực cục bộ, giảm IO mạng
3. Giao diện người dùng đã được thiết kế với kiểu dữ liệu (lịch cho ngày, người quay số), làm cho nó một bước nhỏ từ xác thực

Xác thực ở nhiều nơi trái với khái niệm cách ly trách nhiệm của MVC, do đó "thực hiện cả hai" có vẻ không phù hợp. Là thực hiện xác nhận dữ liệu chỉ trong bộ điều khiển thực sự là phương pháp chi phối?

Tôi không nghĩ có một nơi duy nhất mà bạn có thể nói tất cả các xác nhận nên đi. Điều này là do chúng tôi có một vài chiến lược lập trình cạnh tranh khác nhau làm việc cùng nhau trong một trang web mvc asp.net tiêu chuẩn.

Đầu tiên chúng ta có ý tưởng tách logic miền thành các mô hình, logic 'hành động' thành các bộ điều khiển và hiển thị thành Chế độ xem. Điều này dựa trên ý tưởng, tất cả logic sẽ diễn ra trên máy chủ với trình duyệt chỉ đơn giản là cung cấp kết xuất của chế độ xem.

Sau đó, chúng tôi mở rộng Chế độ xem bằng cách sử dụng javascript phía máy khách. Điều này rất tiên tiến ngày nay đến nỗi ý tưởng 'trang web một trang' với Jquery / loại trực tiếp / góc cạnh là thông lệ.

Cách thực hành này có thể tương đương với việc viết toàn bộ ứng dụng phía máy khách, chính nó thực hiện một mẫu MVC hoặc MVVM. Chúng tôi chê bai Chế độ xem đối tượng truyền dữ liệu và Bộ điều khiển đến điểm cuối dịch vụ. Di chuyển tất cả logic nghiệp vụ và giao diện người dùng vào máy khách.

Điều này có thể cung cấp trải nghiệm người dùng tốt hơn, nhưng bạn phải tin tưởng một khách hàng về cơ bản không đáng tin cậy. Vì vậy, bạn vẫn cần phải thực hiện logic xác thực trên máy chủ, bất kể khách hàng của bạn xác thực trước các yêu cầu của nó tốt đến mức nào.

Ngoài ra, chúng tôi thường có các yêu cầu xác nhận mà khách hàng không thể thực hiện. ví dụ. 'Id mới của tôi có độc đáo không?'

Bất kỳ ứng dụng nào bạn tạo với mục tiêu mang lại trải nghiệm / hiệu suất tốt nhất sẽ nhất thiết phải mượn cho nhiều mô hình lập trình và thỏa hiệp với chúng để đạt được mục tiêu.

Xác thực ở nhiều nơi trái với khái niệm cách ly trách nhiệm của MVC, do đó "thực hiện cả hai" có vẻ không phù hợp.

Có thể có nhiều trách nhiệm xác nhận để xem xét ở đây? Như bạn đã nói trong số 3 của bạn:

Giao diện người dùng đã được thiết kế với kiểu dữ liệu (lịch cho ngày, người quay số), làm cho nó một bước nhỏ từ xác thực

Vì vậy, có thể đó là:

Xem : Xác thực loại đầu vào, định dạng, yêu cầu ... xác thực đầu vào cơ bản của người dùng không liên quan gì đến logic nghiệp vụ. Nắm bắt tất cả những thứ mượt mà này trước khi chúng tôi tạo ra lưu lượng truy cập mạng bằng cách yêu cầu máy chủ.

Mô hình : Xác thực mối quan tâm kinh doanh của dữ liệu. Đó có phải là một giá trị pháp lý theo các quy tắc kinh doanh? Vâng, đó là một giá trị số (chúng tôi đảm bảo rằng trong chế độ xem), nhưng nó có ý nghĩa không?

Chỉ là một ý nghĩ.

Tôi sẽ giả định rằng bạn cần xác nhận cho sự kiên trì.

Không chỉ Xem, mà Mô hình cũng không nên xử lý xác nhận. Trong những ngày ở CNTT tôi đã nhận ra DDD là một trong những cách để đảm bảo bạn đang thực sự làm mọi thứ một cách chính xác, tức là. các lớp học thực sự chịu trách nhiệm cho những gì họ nên được.

Khi theo thiết kế hướng tên miền, các mô hình của bạn bao gồm logic kinh doanh của bạn và đó là nó. Nhưng chúng không bao gồm xác nhận, tại sao không?

Giả sử bạn đã sử dụng đến mức bạn đang sử dụng Data Mapperthay vì Active Recordduy trì lớp miền của mình. Tuy nhiên, bạn vẫn muốn các mô hình được xác thực, vì vậy bạn thêm xác thực vào Mô hình của mình.

interface Validation
{
    public function validate();
}

class ConcreteModel extends MyModel implements Validation
{
    public function validate() { // the validation logic goes here }
}

Logic xác thực đảm bảo, bạn có thể chèn chính xác mô hình vào cơ sở dữ liệu MySQL của mình ... Vài tháng trôi qua và bạn quyết định, bạn cũng muốn lưu trữ Mô hình của mình trong cơ sở dữ liệu noQuery, cơ sở dữ liệu yêu cầu các quy tắc xác thực khác với MySQL.

Nhưng bạn có một vấn đề, bạn chỉ có 1 phương thức xác nhận, nhưng cần xác thực Modeltheo 2 cách khác nhau.

Các mô hình nên làm những gì họ có trách nhiệm làm , họ nên chăm sóc logic kinh doanh của bạn và làm điều đó tốt. Xác nhận được gắn với sự kiên trì, không phải logic kinh doanh, do đó xác nhận không thuộc về một mô hình .

ValidatorThay vào đó, bạn nên tạo s, sẽ lấy một mô hình để xác thực trong hàm tạo của chúng làm tham số, triển khai Validationgiao diện và sử dụng các Validators này để xác thực các đối tượng của bạn.

interface Validation
{
    public function validate();
}

class MySQLConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model here
    }
}

class RedisConcreteModelValidator implements Validation
{
    public function __construct(ConcreteModel $model) { }

    public function validate()
    {
        // you validate your model with different set of rules here
    }
}

Nếu bất cứ lúc nào trong tương lai quyết định bạn muốn thêm một phương thức xác thực khác cho một lớp kiên trì khác (vì bạn đã quyết định Redis và MySQL không còn cách nào nữa), bạn sẽ chỉ tạo một phương thức khác Validatorvà sử dụng bộ IoCchứa của mình để có được ví dụ phù hợp trên của bạn config.

Đối với nhiều nhà phát triển, các mô hình Fat chống lại Bộ điều khiển xấu xí ngu ngốc là phương pháp được ưa thích.

Khái niệm cơ sở trong văn bản là

... Vì vậy, hãy luôn nhớ rằng Model không chỉ là cơ sở dữ liệu. Ngay cả dữ liệu bạn nhận được từ các dịch vụ web cũng có thể được thể hiện dưới dạng Mô hình! Vâng, ngay cả nguồn cấp dữ liệu Atom! Các khung làm nổi bật các giới thiệu về Mô hình, hầu như không bao giờ giải thích được sự trả trước này, điều này chỉ làm trầm trọng thêm những hiểu lầm.

và

Chế độ xem chỉ nên liên quan đến việc tạo và trình bày giao diện người dùng để người dùng có thể truyền đạt ý định đến Mô hình . Bộ điều khiển là bộ điều phối chuyển các đầu vào UI thành các hành động trên Mô hình và truyền lại đầu ra từ bất kỳ Chế độ xem nào đã được biết về (các) Mô hình mà nó trình bày. Bộ điều khiển phải xác định hành vi ứng dụng chỉ theo nghĩa là chúng ánh xạ đầu vào của người dùng vào các cuộc gọi trong Mô hình, nhưng ngoài vai trò đó thì rõ ràng tất cả logic ứng dụng khác được chứa trong Mô hình. Bộ điều khiển là những sinh vật thấp kém với mã tối thiểu chỉ cần thiết lập giai đoạn và để mọi thứ hoạt động theo cách có tổ chức.

Chế độ xem chỉ nên liên quan đến việc tạo và trình bày giao diện người dùng để người dùng có thể truyền đạt ý định đến Mô hình là phần quan trọng. Một mô hình nên xác định de dữ liệu được lưu trữ, do đó nó cũng phải chịu trách nhiệm kiểm tra tính hợp lệ của dữ liệu.

Khi lấy hồ sơ của một người, mỗi người phải có một số ID duy nhất do quốc gia cung cấp. Kiểm tra này (nói chung) được thực hiện bởi UNIQUEkiểm tra chính bởi cơ sở dữ liệu. Mỗi số ID đã cho phải đáp ứng một số bước kiểm soát (tổng các chữ số lẻ phải bằng tổng các chữ số chẵn, v.v.). Các loại điều khiển nên được thực hiện bởiModel

Bộ điều khiển đang thu thập dữ liệu từ Modelvà chuyển nó đến View, hoặc đảo ngược, thu thập dữ liệu người dùng thông qua Viewvà chuyển nó đến Model. Bất kỳ hạn chế truy cập dữ liệu và xác nhận nó không nên được thực hiện bởi Controller. Chính Controllerngười thu thập dữ liệu cookie và đó là người Modelkiểm tra xem đó có phải là phiên hợp lệ hay người dùng có quyền truy cập vào phần này của ứng dụng.

Viewlà giao diện người dùng thu thập dữ liệu từ người dùng hoặc trình bày dữ liệu cho người dùng. Kiểm tra đơn giản có thể được thực hiện bằng cách Viewgiống như địa chỉ e-mail đầu vào của người dùng hay không (do đó cũng có thể được thực hiện trong Chế độ xem) IMO.

Chế độ xem là phía máy khách và bạn không nên đẩy đầu vào của người dùng. Javascripts có thể không chạy được ở phía máy khách, người dùng có thể sử dụng các tập lệnh viết tay để thay đổi chúng hoặc vô hiệu hóa tập lệnh bằng trình duyệt. Bạn có thể thiết lập các tập lệnh xác thực phía máy khách, nhưng không bao giờ bạn nên không bao giờ đẩy chúng và thực hiện kiểm tra thực sự trên Modellớp.

Các khung nhìn nên thực hiện xác nhận cho các mục đích ff:

1. ) Xác thực giao diện người dùng có thể giảm lưu lượng dữ liệu trong máy chủ của bạn.
2. ) nó xử lý dữ liệu không hợp lệ trước khi nó có thể di chuyển trong máy chủ của bạn.
3. ) nếu bạn muốn bảo mật cao hơn, kết hợp Xác thực mặt trước và mặt sau sẽ tốt hơn.