Làm cách nào để tránh trùng lặp cấu trúc dữ liệu khi các phần của ứng dụng được viết bằng các ngôn ngữ khác nhau?

Ví dụ, giả sử bạn đang viết một ứng dụng bằng Java .

Ứng dụng của bạn giao tiếp với một máy chủ API được viết bằng Python .

Máy chủ Python giao tiếp với cơ sở dữ liệu SQL .

Bạn cũng có một trang web cho ứng dụng của bạn được viết bằng JavaScript .

Với 4 ngôn ngữ khác nhau, thật dễ dàng để kết thúc việc lặp lại về cơ bản cùng một cấu trúc dữ liệu 4 lần khác nhau.

Ví dụ: một Userloại có thể trông như thế này (mã giả):

type User {
  integer id;
  string name;
  timestamp birthday;
}

Mỗi phần của dự án sẽ cần một số loại đại diện cho User. Các phần Java và Python sẽ cần hai classkhai báo khác nhau . Cơ sở dữ liệu sẽ cần một Userkhai báo bảng. Và trang web kết thúc sẽ cần phải đại diện Userquá.

Lặp lại kiểu này 4 lần khác nhau thực sự phá vỡ nguyên tắc Đừng lặp lại chính mình . Ngoài ra có một vấn đề là nếu Userloại bị thay đổi thì những thay đổi này cần phải được lặp lại ở mọi phần khác nhau của dự án.

Tôi biết rằng thư viện protobuf của Google cung cấp một loại giải pháp cho vấn đề này trong đó bạn viết cơ sở hạ tầng bằng một cú pháp đặc biệt và sau đó thư viện tạo ra một khai báo cấu trúc cho bạn bằng nhiều ngôn ngữ lập trình khác nhau. Nhưng điều này vẫn không giải quyết được vấn đề phải lặp lại logic xác thực cho các loại của bạn.

Có ai có bất kỳ đề xuất hoặc liên kết đến sách / bài đăng blog về điều này?

Bạn không. Hoặc thực sự, bạn không nên.

Nếu bạn nghĩ về ứng dụng, máy chủ và trang web của bạn như là các bối cảnh riêng biệt, thì có nghĩa là có các cấu trúc trùng lặp. Lý do tại sao nó có thể là một điều tốt:

• Các cấu trúc tương tự, nhưng không giống nhau. Ngay cả khi 90% cấu trúc là giống nhau trên tất cả các bối cảnh. Đó là 10% sẽ khiến bạn đau đầu.
• Mô hình và triển khai có thể khác nhau. Khi các ngôn ngữ và khung khác nhau được sử dụng, sẽ rất khó để có cùng một triển khai trên tất cả chúng
• Các cấu trúc được chia sẻ trở thành một phụ thuộc, cần phải được quản lý. Có sự phụ thuộc được chia sẻ làm phức tạp đáng kể sự phát triển, vì sự thay đổi lớn trong một bối cảnh là rất lớn trong một bối cảnh khác. Vì vậy, rất nhiều nỗ lực là cần thiết để phối hợp phát triển sự phụ thuộc được chia sẻ này
• Các bối cảnh khác nhau có triển khai khác nhau. Ngay cả khi bạn quản lý để chia sẻ cùng cấu trúc dữ liệu và cùng mã xác thực trên tất cả các bối cảnh, vẫn có thể xảy ra rằng phiên bản mới của một bối cảnh được triển khai trong khi các bối cảnh khác ở phiên bản cũ, do đó, vẫn cần phải đồng bộ hóa trong các phiên bản. được giải quyết

Mặc dù nguyên tắc DRY là tuyệt vời, tôi nghĩ rằng việc chia sẻ cấu trúc dữ liệu trên các bối cảnh hoặc các lớp tạo ra nhiều vấn đề hơn nó giải quyết. Đặc biệt là nếu dự án phát triển đủ lớn để những người khác nhau đang làm việc trên các bối cảnh khác nhau.

Tôi nghĩ rằng @Euphoric liệt kê một vài lý do chính đáng để không sao chép mã của bạn. Tuy nhiên, nếu bạn phải làm như vậy, tôi khuyên bạn nên sử dụng tạo mã.

Tìm dạng chính tắc của dữ liệu

Để làm như vậy một cách hiệu quả, trước tiên bạn phải khám phá hình thức chính tắc của dữ liệu là gì. Đây có phải là lược đồ SQL hoặc các lớp trong chương trình Java của bạn không?

Xuất phát (tự động) các hình thức khác từ nó

Sau đó, nghĩ ra một cách để tạo ra tất cả các hình thức khác từ dạng chính tắc. Ví dụ: giả sử dạng chính tắc của bạn là lược đồ SQL, bạn có thể tạo mã JavaScript, Java và Python từ đó một cách dễ dàng (SQL dễ dàng được phân tích cú pháp và là ứng cử viên tốt cho nguồn chính tắc).

Chứa sự khác biệt

Thật dễ dàng để đánh dấu các phần của mã được tạo là "không chạm" - theo cách này bạn phù hợp với sự khác biệt cần thiết giữa tất cả các cách biểu diễn khác nhau (ví dụ: mã tùy chỉnh bạn đã viết cho giao diện JS và phụ trợ Java) cần được bảo tồn trong suốt quá trình tái sinh.
Lấy một ví dụ từ Git; khi nó mở ra một trình soạn thảo để cho phép bạn nhập một thông điệp tập tin đã có chứa một số văn bản cam kết, nhưng nó có # -------- >8 --------dấu hiệu để biết được nơi bạn mục đích nội dung, và nơi nó văn bản tự động tạo ra bắt đầu.

Tuy nhiên, nếu bạn có thể - tránh trùng lặp như vậy. Nó là PITA, ngay cả khi hầu hết mã của bạn được tạo tự động.

Câu trả lời này là một chút thời gian câu chuyện thay vì "đây là một số thực tiễn tốt nhất" - những gì tôi mô tả chính xác là những gì tôi đã từng làm khi gặp vấn đề giống như bạn và cần có cùng một dữ liệu được trình bày trong các phần khác nhau của hệ thống (hoặc, đúng hơn, trong hai hệ thống khác nhau).