Phương pháp phát triển: Giao diện người dùng trong hoặc mô hình miền ra?

Mặc dù tôi chưa bao giờ giao bất cứ thứ gì khi sử dụng Smalltalk, nhưng thời gian ngắn ngủi của tôi chơi với nó chắc chắn đã để lại dấu ấn. Cách duy nhất để mô tả trải nghiệm là MVC theo đúng nghĩa của nó. Về cơ bản, tất cả các công việc nặng nề cho ứng dụng của bạn đều được thực hiện trong các đối tượng kinh doanh (hoặc mô hình miền nếu bạn có khuynh hướng như vậy). Các điều khiển tiêu chuẩn được ràng buộc với các đối tượng kinh doanh theo một cách nào đó. Ví dụ: một hộp văn bản được ánh xạ tới trường của một đối tượng (chính trường đó là một đối tượng để dễ thực hiện). Một nút sẽ ánh xạ tới một phương thức. Tất cả điều này được thực hiện với một API rất đơn giản và tự nhiên. Chúng ta không phải suy nghĩ về các đối tượng ràng buộc, vv Nó chỉ hoạt động.

Tuy nhiên, trong nhiều ngôn ngữ và API mới hơn, bạn buộc phải suy nghĩ từ bên ngoài. Đầu tiên với C ++ và MFC, và bây giờ với C # và WPF, Microsoft đã khiến thế giới nhà phát triển bị cuốn hút vào các trình xây dựng GUI nơi bạn xây dựng ứng dụng của mình bằng cách triển khai trình xử lý sự kiện . Phát triển Java Swing không quá khác biệt, chỉ có bạn đang viết mã để khởi tạo các điều khiển trên biểu mẫu. Đối với một số dự án, thậm chí có thể không bao giờ có mô hình miền - chỉ xử lý sự kiện. Tôi đã ở trong và xung quanh mô hình này cho hầu hết người chăm sóc của tôi.

Mỗi cách buộc bạn phải suy nghĩ khác nhau. Với phương pháp Smalltalk, tên miền của bạn thông minh trong khi GUI của bạn bị câm. Với cách tiếp cận VisualStudio mặc định, GUI của bạn thông minh trong khi mô hình miền của bạn (nếu nó tồn tại) khá thiếu máu.

Nhiều nhà phát triển mà tôi làm việc nhìn thấy giá trị trong cách tiếp cận Smalltalk và cố gắng đánh bóng cách tiếp cận đó vào môi trường VisualStudio. WPF có một số tính năng ràng buộc động làm cho nó có thể; nhưng có những hạn chế. Chắc chắn một số mã thuộc mô hình miền kết thúc trong các lớp GUI.

Vì vậy, cách nào bạn thiết kế / phát triển mã của bạn? Tại sao?

• GUI đầu tiên. Tương tác người dùng là tối quan trọng.
• Tên miền đầu tiên. Tôi cần đảm bảo hệ thống chính xác trước khi chúng tôi đặt UI lên nó.

Có những ưu và nhược điểm cho cả hai cách tiếp cận. Mô hình miền phù hợp ở đó với các thánh đường pha lê và chiếc bánh trên bầu trời. GUI phù hợp với đó nhanh chóng và bẩn (đôi khi thực sự bẩn).

Và đối với một phần thưởng bổ sung: Làm thế nào để bạn chắc chắn rằng mã có thể được duy trì?

Cũng không

Trong những năm qua, tôi đã phát triển phần mềm, tôi thấy mình phải thực hành cả một phương pháp đầu tiên bởi vì luôn có một "nền tảng trung gian" để xem xét. Đặt giao diện giữa mã UI và mã doanh nghiệp và thỏa thuận về những gì UI cần tại thời điểm này từ miền.

Hãy để tôi làm cho một con số để làm cho khái niệm này rõ ràng:

  +------+
  |  UI  | <- Think about how to make an effective user interface
  +------+
      |
      |
 +----------+
 | Contract | <--- This part over here is really REALLY important, man!
 +----------+
      |
      |
+--------------+
| Domain model | <- Think about what the user needs
+--------------+ 

Bằng cách đó, bạn có thể lặp lại hoạt động trên UI và mô hình miền riêng biệt nếu mặt bằng ở giữa làm cho nó rõ ràng về dữ liệu mà UI có thể nhận được.

Lý do tôi thấy lý do tại sao một số dự án trở nên không thể hiểu được là vì giao diện giữa dữ liệu và bản trình bày đã vội vàng hoặc không có sẵn (với mã xử lý dữ liệu trực tiếp nằm trong ui). Tôi đã thấy rất nhiều dự án nơi mã cơ sở dữ liệu nằm trong mã mẫu mà tôi đã mất niềm tin vào nhân loại. Chỉ có một vài dự án mà tôi đã thấy có phục hồi mặt đất cứng nhắc này mà mất niềm tin.

Nó không thực sự quan trọng để từ đó chấm dứt nơi bạn bắt đầu đầu tiên ... điều quan trọng là bạn đã có mà tách rõ ràng về mối quan tâm tại chỗ. Hợp đồng đó ở giữa khá nhiều định nghĩa ứng dụng hoặc hệ thống trong tay. Hãy nghĩ về điều đó trước khi đi từ dưới lên hoặc từ trên xuống .

Tên miền đầu tiên. Tôi cần đảm bảo hệ thống chính xác trước khi chúng tôi đặt UI lên nó.

Không có gì khác có thể được thực hiện để làm việc - ngoại trừ trong các trường hợp đơn giản.

Bắt đầu từ giao diện người dùng thường dẫn đến phần mềm dễ hỏng, có vẻ như rất vui, nhưng thường có vấn đề nghiêm trọng trong mô hình.

Đây không phải là một giao diện người dùng đầu tiên chắc chắn sẽ thất bại - nếu mô hình đủ đơn giản thì giao diện người dùng có thể được xây dựng trước với sự tự tin rằng cuối cùng mô hình sẽ hoạt động tốt.

Trong mọi trường hợp mô hình không thể dễ dàng được tưởng tượng, nó phải được xây dựng trước.

Trường hợp xấu nhất là một số lập trình viên nghĩ rằng họ có thể tưởng tượng mô hình. Họ có thể đã bỏ qua các chi tiết quan trọng, trường hợp đặc biệt, trường hợp ngoại lệ hoặc cân nhắc hiệu suất. Vì GUI đã được xây dựng và nhiều điều cần cân nhắc, nên mô hình này rất tệ.

Điều này thực sự phụ thuộc vào ứng dụng trong tầm tay.

Nếu bạn đang xây dựng một ứng dụng máy khách / máy chủ đóng thì cách tiếp cận sẽ đủ; vì bạn sẽ thao túng mặt sau cho phù hợp với nhu cầu phía trước chắc chắn.

Nếu bạn đang xây dựng một ứng dụng máy khách / máy chủ mở, nơi một dịch vụ web tiềm năng sẽ được khách hàng của bạn tiếp xúc để sử dụng thì việc nhận thức được dịch vụ đó có thể được sử dụng bởi khách hàng như thế nào để phát triển giao diện người dùng là rất quan trọng.

Thông thường, vào thời điểm muộn liên quan đến việc thúc đẩy các chu kỳ lặp nhỏ trong quá trình phát triển (Scrum, Kanban, v.v.), mặt trước và mặt sau được thực hiện song song. Đó là về việc cung cấp những gì bạn cần cho lần lặp đó; coi thường việc xây dựng nó trong trường hợp chúng ta cần nó tiếp cận . Theo cách tiếp cận song song, cả hai đầu ở gần nhau hơn trong suốt quá trình phát triển, điều này có thể làm giảm nhu cầu thay đổi liên tục khi mặt trước và mặt sau hợp nhất. Đây là cách tiếp cận ưa thích của tôi khi khả thi.

Bạn đã đề cập ...

... WPF có một số tính năng ràng buộc động làm cho nó có thể; nhưng có những hạn chế. Chắc chắn một số mã thuộc mô hình miền kết thúc trong các lớp GUI ...

Không chắc chắn những gì bạn có ý nghĩa của một số ? WPF và SL đều được ghi nhận cho chức năng ràng buộc của họ. Nó là vô tận. Nếu bạn bị buộc phải đặt mã trong Chế độ xem của mình trong ứng dụng WPF dựa trên MVVM thì cần phải giải quyết vấn đề. Các hành vi được đính kèm là một cách để thực hiện hành vi mà không cần tham gia vào các sự kiện trong Chế độ xem, cũng như nhiều cách tiếp cận khác để đảm bảo Chế độ xem của bạn luôn sạch sẽ.

Giao diện người dùng từ lập trường tương tác người dùng sẽ không liên quan gì đến việc triển khai mặt sau. Mặt sau kết thúc công việc duy nhất cho một mặt trước là cung cấp dữ liệu thông qua xử lý dữ liệu hoặc các phương tiện khác. Điều này liên quan trở lại các loại ứng dụng đang được phát triển.

Đảm bảo mã nguồn có thể duy trì được thực sự là một câu hỏi hoàn toàn khác. Ở mức độ cao, nó liên quan đến các thực tiễn mã hóa tốt nhất cùng với các mô hình, kiến ​​trúc và công nghệ đã được chứng minh.

Tôi thích thiết kế UI cơ bản trước tiên (ngay cả khi nó chỉ trên giấy), với đầu vào từ khách hàng. Khách hàng có thể không thực sự biết họ muốn gì cho đến khi họ nhìn thấy nó. Bạn không thể luôn tin tưởng những gì khách hàng nói với bạn. Bạn có thể đầu tư hàng tuần để viết một mô hình miền mạnh mẽ chỉ để tìm ra nó không phù hợp với những gì khách hàng nhận ra họ muốn sau khi họ bắt đầu nhìn thấy các nguyên mẫu UI.

Chúng tôi cố gắng lái phần mềm của chúng tôi với các bài kiểm tra tự động. Kiểm tra giao diện người dùng tự động là khá tốn thời gian. Các kịch bản để kiểm tra một số giá trị trên bàn điều khiển dễ dàng hơn.

Với ý nghĩ đó, chúng tôi khá cẩn thận để tách biệt logic kinh doanh khỏi UI.

Tôi còn nhớ có lần nhà phát triển chính mắng tôi rằng kiến ​​trúc Tài liệu / Chế độ xem bị coi là lỗi thời khi tôi đề nghị rằng chúng tôi cần ngừng ràng buộc tất cả mã doanh nghiệp của mình với UI (và lúc đó chúng tôi đang sử dụng win32 trong C ++ điều thậm chí không phải là vấn đề của chúng tôi). Tôi chỉ đơn giản là chết lặng.

IMNSHO, đơn giản là không có lý do gì để không có ít nhất một lớp doanh nghiệp so với lớp UI. Nếu sản phẩm của bạn làm bất cứ điều gì thú vị nhẹ thì việc tách biệt này để cho phép tái sử dụng mã là hoàn toàn cần thiết.

Là một nhà phát triển C #, tôi chắc chắn không nghĩ rằng bạn đang thích làm việc bên ngoài. Tôi thích làm mô hình miền đầu tiên, thực sự.

Đối với WPF, nhược điểm duy nhất của mô hình mà tôi đã mô tả, sau đó, là đôi khi bạn cần phải qua trung gian giữa giao diện người dùng và mô hình miền của bạn. Tuy nhiên, trong khi điều đó đôi khi có nghĩa là nhiều công việc hơn, nó cũng có nghĩa là mã sạch hơn.

Chắc chắn, tên miền đầu tiên!

Vẻ đẹp của Smalltalk là bạn có thể dễ dàng "lái" một mô hình miền theo nhiều cách, bao gồm cả việc "in nó" từ không gian làm việc hoặc thanh tra. Chỉ khi bạn chắc chắn rằng tên miền của bạn hoạt động như mong muốn, bạn mới dám tập trung vào việc xây dựng GUI hoàn hảo.

Điều đó không có nghĩa là Smalltalker không hoạt động đồng thời trên cả hai, nhưng khi GUI của bạn không thực hiện logic nghiệp vụ, bạn thường sửa mô hình miền trước, thay vì đặt các trường hợp đặc biệt vào GUI của bạn.