2009-07-23 34 views
15

Đường ruột của tôi nói với tôi rằng việc đặt một định dạng trong một định dạng khác là sai, nhưng tôi dường như không thể đưa ra các lý do cụ thể.tại sao nhúng JSON vào XML xấu?

<root> 
<stuff> 
    thing 
</stuff> 
<more> 
    <[!CDATA[{"a":["b","c"]}]]> 
</more> 
</root> 

so với chỉ đặt nó trong xml

<root> 
<stuff> 
    thing 
</stuff> 
<more> 
    <a> 
    b 
    </a> 
    <a> 
    c 
    </a> 
</more> 
</root> 

Hai phần được một cách logic sẽ được phân tích theo mã khác nhau, nhưng như một định dạng trao đổi, là nó ok để trộn và cú pháp phù hợp?

Câu trả lời của bạn có thay đổi không nếu chúng tôi có điểm cuối hiện có phân tích cú pháp phản hồi JSON? Chúng tôi sẽ phải mã hóa điểm cuối này để nhập XML.

+5

Tại sao lưu trữ các tệp sqlite dưới dạng các đốm màu trong cơ sở dữ liệu xấu? –

Trả lời

21

Là một định dạng trao đổi sử dụng hai định dạng, hãy đặt thêm gánh nặng cho những người muốn liên kết với bạn. Bây giờ, họ cần có trình phân tích cú pháp XML một trình phân tích cú pháp JSON.

Nó cũng khiến mọi người khó khăn hơn khi định dạng, vì họ phải chuyển đổi tinh thần các bánh răng khi suy nghĩ về các phần khác nhau trong tệp của bạn.

Cuối cùng, bạn sẽ không thể dễ dàng thực hiện những việc nhìn toàn bộ cấu trúc cùng một lúc. Ví dụ, bạn không thể sử dụng XPath để lấy các bit JSON, cũng như bạn không thể xử lý toàn bộ phản hồi như một đối tượng JavaScript. Bằng cách trộn hai định dạng, bạn nhận được sự cố "tồi tệ nhất của cả hai thế giới" khi nói đến thao tác dữ liệu.

+1

Câu trả lời của bạn có thay đổi không nếu chúng tôi có một điểm cuối hiện có phân tích cú pháp phản hồi JSON? Chúng tôi sẽ phải mã hóa điểm cuối này để nhập XML. –

+0

Vì bạn đã có một giải pháp - nghĩa là; một trình phân tích cú pháp JSON trên đầu trang của một trình phân tích cú pháp XML - sau đó các câu trả lời cho câu hỏi của bạn sẽ liên quan đến tính di động, khả năng đọc, khả năng bảo trì và hương vị thuần cũ. Chắc chắn nó hoạt động * bây giờ *, nhưng hãy nghĩ ai có thể đọc nó trong tương lai, bạn có thể chuyển XML cho ai, làm thế nào bạn sẽ giải thích cho họ tại sao họ cần một trình phân tích cú pháp JSON ở cuối nó, và cứ thế. Nó có vẻ như bạn đang đưa ra công việc cho bây giờ có thể dẫn đến nhiều công việc được tạo ra sau này. – shuckster

+1

@Paul: Nếu nó hoạt động cho việc triển khai hiện tại của bạn thì không có lý do gì để thay đổi nó ngay bây giờ. Tuy nhiên, nếu bạn bắt đầu nghĩ ra những cách sáng tạo (đọc: hôi thối) để giải quyết các vấn đề mà Laurence mô tả đó là khi bạn muốn gắn bó với cái này hay cái kia. –

7

Nó phân loại như cuộc tranh luận bình thường hóa cơ sở dữ liệu. Nó sạch hơn và thanh lịch hơn để làm mọi thứ trong XML thuần túy (hoặc chuẩn hóa lược đồ cơ sở dữ liệu của bạn), theo cách đó bạn không nhất thiết phải kết hợp với việc triển khai cụ thể của bạn. Nhưng nếu sau đó bạn phải chuyển đổi XML thành các đối tượng JavaScript (hoặc tham gia 5 bảng cho mỗi SELECT damned), bạn có thể sẽ viết nhiều mã bổ sung và phát sinh các lần truy cập hiệu suất không cần thiết.

Tất cả phụ thuộc vào cách bạn cân bằng sự tiện lợi với tính chính xác chính xác. Nếu đây là một định dạng trao đổi XML sẽ được chuẩn hóa bởi W3C và được hàng triệu người sử dụng thì Chúa yêu quý, không sử dụng JSON. Nếu điều này là cho một ứng dụng trong nhà mà sẽ chỉ được xử lý bằng mã bạn tự mình đã viết sau đó vít nó, chỉ cần ném JSON trong đó và di chuyển trên!

+5

+1. thực hành tốt là tốt. nhưng họ không thể thay thế tư duy tốt. đôi khi biết các mẫu không phải là giải pháp tốt nhất cho một vấn đề. đôi khi một hack là điều đúng. bất cứ điều gì bạn làm, biết TẠI SAO bạn làm điều đó, và nó càng lộn xộn, bạn càng cần phải ghi lại nó và đóng gói đống lộn xộn ở đâu đó, vì vậy bạn có thể dễ dàng thay thế nó một ngày nào đó ... :) – back2dos

3

Theo ý kiến ​​của tôi, XML là biểu diễn truyền dữ liệu được ưu tiên hơn, nhưng JSON thì càng biểu cảm hơn nhiều khi nói đến Bản đồ và mảng. Tôi sẽ không có vấn đề với việc nhúng JSON vào xml để đại diện cho một danh sách hoặc bản đồ.