Tôi biết nó đắt tiền nhưng (IMO) Tôi tin rằng đó là một thực hành rất tốt. Tôi đang nói về các quy tắc như nói, bạn không thể lưu Hóa đơn nếu bạn không phải là người bán hàng ... vì vậy, trong trường hợp đó, hãy ném một ngoại lệ với nội dung 'bạn không được ủy quyền' hoặc ...
Một cách tiếp cận khác là nó sẽ có các đối tượng có trạng thái hoặc một cái gì đó tương tự
Có cách tiếp cận nào khác không? bạn cảm thấy thế nào
Câu trả lời:
Nếu bạn có nghĩa là đại diện cho kiểm tra quy tắc kinh doanh cá nhân với các ngoại lệ, thì tôi không nghĩ đó là một ý tưởng rất tốt. Nhiều lần bạn phải báo cáo nhiều hơn một điều kiện thất bại, và không dừng lại ở điều kiện đầu tiên.
Mặt khác, tôi tin rằng kiểm tra tất cả các quy tắc và sau đó ném một ngoại lệ với bản tóm tắt là một thực hành tốt.
Trong ví dụ bạn đã cho chúng tôi, tôi nghĩ rằng việc đưa ra một ngoại lệ là một ý tưởng tồi. Nếu bạn biết rằng người dùng không được ủy quyền trước khi họ bắt đầu làm việc và bạn vẫn cho phép họ thực hiện một số chức năng và sau đó đập chúng bằng một thông báo SAU KHI họ đã hoàn thành nhiệm vụ, đó chỉ là một thiết kế tồi.
Sử dụng ngoại lệ để thực thi các quy tắc kinh doanh không phải là một thiết kế tốt.
Tôi không thấy giá trị của ngoại lệ trong việc tạo ra logic kinh doanh tốt. Có hàng tá cách tiếp cận để xử lý logic kinh doanh không liên quan đến việc sử dụng một hệ thống nhằm giải quyết các điều kiện bất ngờ trong hoạt động của một hệ thống.
Dự kiến trong logic kinh doanh, các điều kiện sẽ không được đáp ứng; đó là lý do để có nó ở vị trí đầu tiên và bạn không muốn cõng trên cùng một cơ chế xử lý các lỗi I / O bất ngờ, lỗi bộ nhớ và tham chiếu null. Đó là những thất bại của hệ thống, nhưng phát hiện các điều kiện kinh doanh chưa được đáp ứng là hoạt động thành công của hệ thống.
Ngoài ra, nó là một hệ thống đã chín muồi cho những hậu quả không lường trước được. Bởi vì một số ngoại lệ phải được bắt gặp tại một số điểm, bạn có nguy cơ có một ngoại lệ quy tắc kinh doanh mới xảy ra khi bị bắt ở một nơi nào đó mà nó không có ý định hoặc bạn có thể có mã tìm quy tắc kinh doanh bắt những ngoại lệ không thực sự có nghĩa cho nó. Đúng, những điều kiện này có thể được giải thích với các thực tiễn mã hóa tốt, nhưng trong bất kỳ hệ thống không tầm thường nào mà hơn một nhà phát triển đang làm việc, sẽ xảy ra lỗi và bạn chỉ cần hy vọng rằng chúng sẽ không phải là những sai lầm tốn kém.
thể hiện các quy tắc kinh doanh là một chuyện, thực hiện chúng là một việc khác
suy nghĩ về trải nghiệm người dùng; nếu người dùng không phải là nhân viên bán hàng, tại sao lại cung cấp cho họ nút 'tạo hóa đơn' ở tất cả ?
Điều đó phụ thuộc hoàn toàn vào những gì đang được thực hiện.
Đầu tiên, hành vi thực tế bạn muốn là gì? Nếu ai đó đang nhập thông tin của riêng họ, thì từ chối và hộp thoại nói, về cơ bản, "Bạn không thể làm điều đó" có lẽ là chính xác. Nếu đây là người nhập dữ liệu, làm việc từ một đống biểu mẫu, hộp thoại có thể cũng tốt và người nhập dữ liệu có thể đặt các biểu mẫu không hợp lệ vào một đống đặc biệt. Nếu bạn đang xử lý hàng loạt, bạn không muốn tạm dừng mọi thứ, nhưng hãy gắn cờ và chuyển sang phần tiếp theo.
Khi bạn có hành vi, bạn cần quyết định cách bạn sẽ thực hiện nó. Có một trình kiểm tra quy tắc kinh doanh mà ném một ngoại lệ có lẽ là một ý tưởng tốt. Trả lại mã trả về và để nó đi cùng là một điều khác có thể sai và bạn chắc chắn không muốn các mục sai lầm ngày càng xa hơn.
Đừng lo lắng về chi phí hiệu suất. Trong trường hợp một cá nhân nhập dữ liệu, nó không đáng kể so với các lần khác có liên quan. Thông thường, con người sẽ mất nhiều thời gian nhất trong hệ thống đó. Trong trường hợp của một công việc hàng loạt, nếu các trường hợp ngoại lệ là một vấn đề về hiệu suất, thì bạn đang nhập quá nhiều hồ sơ xấu, và trong thực tế xử lý và nhập lại tất cả những điều đó sẽ là một vấn đề nhiều hơn so với các ngoại lệ.
Có một API ngoại lệ mạnh mẽ và được thiết kế phù hợp là rất phù hợp. Sử dụng điều này để thực thi các quy tắc kinh doanh cũng có thể phù hợp. Trong thực tế theo kinh nghiệm của tôi, quy tắc kinh doanh càng phức tạp thì càng có nhiều khả năng nó sẽ bị xử lý theo cách này. Nó thường dễ dàng như vậy nếu không dễ dàng hơn để viết một hệ thống trong đó các trường hợp ngoại lệ được mong đợi hơn là viết logic phân nhánh có thẩm quyền.
Điều này có nghĩa là các quy tắc đơn giản có thể được mô tả trong một câu nói chung nên được thực hiện theo cách phòng ngừa hoặc có thẩm quyền tùy thuộc vào đó là gì. Tuy nhiên, nếu bạn có một quy tắc đa chiều và yêu cầu nhiều hơn ba hoặc bốn yếu tố (đặc biệt nếu việc lựa chọn các yếu tố này dựa trên một hoặc nhiều yếu tố khác) thì mã hóa ngoại lệ có thể được duy trì nhiều hơn. Thông thường trong các trường hợp này, đường dẫn logic sẽ có nhiều ngoại lệ cần phải được ném, (kiểm tra lý do tại sao hành động không thể được thực hiện) sau đó (hoặc ngược lại) có một sự sụp đổ đối với bảo mật (để kiểm tra xem hành động đó có được phép không ), đôi khi sẽ có một số logic tích lũy có thẩm quyền cần được kiểm tra (tính sẵn có của hậu duệ / tổ tiên, tiền thân nói rằng các đối tượng phải được đưa vào, v.v.
Một lợi ích bắt nguồn từ kiểu ném ngoại lệ này là nó cho phép bạn tách ra và sử dụng lại các ngoại lệ tiền thân trên nhiều lĩnh vực trong dự án của bạn. (Đây là bản chất của Lập trình hướng theo khía cạnh.) Bằng cách này, bạn đang gói gọn một khía cạnh cụ thể của các quy tắc kinh doanh chung của bạn trong một thành phần khép kín và có thể duy trì. Nói chung, các thành phần này sẽ tương ứng 1-1 với các thông báo lỗi được ném. (Mặc dù đôi khi bạn sẽ có một thành phần đưa ra một số ngoại lệ khác nhau, nhưng bạn hầu như không bao giờ có cùng một ngoại lệ được ném từ nhiều thành phần.)
Theo tôi, việc thiết kế các hệ thống ngoại lệ dựa trên khó khăn hơn và thời gian phát triển ban đầu dài hơn vì bạn phải xây dựng quy trình ngoại lệ trên tất cả các cấp độ N. Tuy nhiên, những hệ thống này thường ổn định hơn nhiều. Mặc dù không bao giờ có thể thiết kế một hệ thống 'sẽ không thất bại', lợi ích của thiết kế dựa trên ngoại lệ là bạn luôn lường trước được sự thất bại. Đối với hầu hết mọi người, quá trình này có thể phản trực giác. Nó giống như hỏi đường và có ai đó nói với bạn tất cả các đường phố mà bạn không nên bật.