Nếu XML rất tệ, tại sao nhiều người sử dụng nó? [đóng cửa]

Tôi hiểu mục đích của XML, nhưng tôi luôn nghe mọi người phàn nàn về cách BAD của nó? Tôi không thực sự hiểu những gì xấu về nó? Tôi thường nghe các thuật ngữ "cồng kềnh" và "chậm" được ném xung quanh.

Nhưng tôi đoán là lập trình viên, bạn chủ yếu sử dụng nó để làm gì? Và bạn có thực sự coi nó là "xấu" .... bởi vì nếu có, rất nhiều người sử dụng nó để vận chuyển dữ liệu ...

Xml là tuyệt vời cho những gì nó được thiết kế - một giao thức truyền dữ liệu trung lập, có thể đọc được của con người với một số khả năng để thực thi xác thực dữ liệu ở mức thấp. Tôi nghi ngờ bất cứ ai sử dụng Xml theo cách này đều có khiếu nại thực sự. Đây có phải là định dạng dây succint nhất? Không. Nhưng có những lựa chọn tồi tệ hơn. Có nhanh như đọc định dạng nhị phân tùy chỉnh của bạn? Không. Nhưng các đối tác kinh doanh của bạn có thể đọc nó trong bất kỳ ngăn xếp nào họ đang sử dụng.

Tuy nhiên, vấn đề là con người - đặc biệt là giống chó được gọi là kiến ​​trúc sư doanh nghiệp - là ác quỷ và lấy những điều tốt và làm cho chúng xấu đi. Trong trường hợp của Xml, phần đầu của thế kỷ này đã xem Xml là cái búa phổ quát cho mọi vấn đề CNTT. Rắc rắc trong một thiết kế nhỏ của ủy ban và bạn kết thúc với một số điều quái dị khủng khiếp như SOAP và oXML . Không ai trong số đó nên được ước muốn trên kẻ thù, không bao giờ kết bạn với bạn bè hoặc đồng nghiệp.

XML chỉ là một công cụ có nhiều hương vị và cách sử dụng. XML vượt trội ở một số thứ và hút vào những thứ khác. Tôi nghĩ một trong những vấn đề là mọi người đã thấy XML "doanh nghiệp" phức tạp không cần thiết với các không gian tên và crap rải rác xung quanh (SOAP, có ai không?). Mẹo để thiết kế các định dạng XML cho con người là thêm ý nghĩa thực sự vào dữ liệu trong khi không khiến chúng bị quá tải để đọc.

Một trong những điều mà mọi người gặp phải là vấn đề XML đôi khi gây ra một số ký tự hoặc một số dấu ngoặc bị thiếu. Tuy nhiên, có cả nhược điểm và nhược điểm. Ưu điểm là bạn không có sự mơ hồ như bạn có với HTML trong đó các trường hợp cú pháp bán không hợp lệ khác nhau có thể được diễn giải khác nhau.

Nhược điểm là tác giả khó hơn một chút và khó học hơn. Tôi đồng ý rằng có một lập luận được đưa ra rằng web sẽ không phát triển quá nhanh nếu HTML nghiêm ngặt như XML, nhưng tôi cũng cho rằng chúng ta sẽ vui mừng nếu ngày nay nó hoạt động. :)

Ngoài ra, không sử dụng nó cho tất cả mọi thứ chỉ vì bạn có thể, có ý thức và phán đoán để áp dụng nó một cách thích hợp. Nếu tất cả những gì bạn có là XML, bạn có xu hướng luôn là một phép chuyển đổi XSLT khỏi những gì bạn muốn. :)

Tôi cho rằng định dạng chỉ thực sự quan trọng khi con người cần tương tác với nó. Nếu bạn đang viết một số chương trình nối tiếp một cái gì đó và gửi nó đến một nơi nào đó mà nó sẽ được sử dụng bởi một chương trình khác, thì ai quan tâm nó trông như thế nào miễn là nó hiệu quả nhất có thể? Sử dụng định dạng nhị phân hoặc thỏ và kỳ lân cho tất cả những gì tôi quan tâm.

Ưu điểm của XML

• Bao gồm rất nhiều trường hợp cạnh mà YAML và JSON không
• Có các công cụ tuyệt vời để phân tích cú pháp và xác thực XML trong một loạt các nền tảng và ngôn ngữ khác nhau
• XML có thể dễ dàng và mạnh mẽ được chuyển đổi sang định dạng khác (thông qua những thứ như XSLT)
• Các tài liệu XML hợp lý rất đơn giản để con người đọc và chỉnh sửa; đừng nói với tôi JSON dễ hơn, không phải vậy :)
• XML tự mô tả ở một mức độ nào đó, tức là nó trực tiếp chứa thông tin về cấu trúc và ý nghĩa của nó (trái ngược với hầu hết các định dạng nhị phân)
• Xử lý mã hóa
• Không gian trắng, giúp sử dụng đa nền tảng dễ dàng hơn
• Phá vỡ nếu nó không được định dạng tốt (Đảm bảo dữ liệu có cấu trúc chính xác)
• Nó không phải là SGML

Nhược điểm

• Rực rỡ
• Nó không nhanh như phân tích cú pháp như nhị phân
• Phá vỡ nếu nó không được định dạng tốt (làm hỏng ứng dụng của bạn)

Sử dụng tốt

• Tập tin cấu hình
• Định dạng trao đổi dữ liệu
• Phiên bản định dạng tệp đàn hồi
• Lưu trữ tài liệu trong cơ sở dữ liệu

Sử dụng không tốt

• Định dạng truyền dữ liệu
• Đối tượng nối tiếp
• Lưu trữ dữ liệu quan hệ trong cơ sở dữ liệu
• Định dạng tệp cho các kịch bản I / O hiệu suất cao

Jeff Atwood có một bài đăng blog khá hay tại XML: Thuế khung góc về điều này nếu bạn muốn có một nguồn nói về nó.

Các ứng dụng phổ biến nhất tôi có cho nó là:

• Dịch vụ nói chuyện với nhau. Ví dụ: một trang web sử dụng hệ thống quản lý nội dung phải gửi một số dữ liệu vào hệ thống quản lý quan hệ khách hàng và điều này được thực hiện với XML.

• Cấu hình lưu trữ. Web.config và app.config là các ví dụ phổ biến nhưng các tập lệnh nAnt cũng có thể sử dụng một số XML cho chúng.

Tôi không nghĩ rằng nó là tối ưu nhưng một mình nó không làm cho nó tồi tệ với tâm trí của tôi.

Hai lý do:

1. Có rất nhiều lập trình viên tồi tệ ngoài kia. XML có thể xấu, nhưng nó cũng đơn giản (ít nhất là trên bề mặt) và làm cho nó rất dễ dàng để viết phần mềm xấu. Sắp xếp như VB.
2. Rất nhiều người đưa ra các quyết định này không phải là lập trình viên, nhưng các loại hình kinh doanh chỉ nghe nói rằng "mọi người đều sử dụng XML" và vì vậy họ quyết định họ cũng muốn sản phẩm của họ sử dụng XML.

Tôi thường nghe các thuật ngữ "cồng kềnh" và "chậm" được ném xung quanh.

Đây không phải là cú pháp nhỏ gọn nhất, nhưng rõ ràng đây là cú pháp biểu cảm nhất. Con người có đọc được không? phụ thuộc vào cách bạn thiết kế ngôn ngữ của bạn. Hầu hết mọi người không thiết kế ngôn ngữ cho XML, họ chỉ tuần tự hóa các đối tượng dưới dạng XML.

Tại sao nhiều người sử dụng nó?

Nó có mặt khắp nơi. Bạn có thể truy vấn cơ sở dữ liệu XML bằng XQuery, chuyển đổi kết quả bằng XSLT thành XHTML hoặc Atom, lấy định dạng Atom hoặc XML khác từ các dịch vụ web khác, nhận XML từ người dùng bằng XForms, xác thực nó bằng XMLSchema, Thư giãn NG hoặc Schematron, xử lý nó với XProc, lưu nó trở lại cơ sở dữ liệu với XQuery Update. Tất cả các công cụ này đều hiểu XML, do đó không cần ánh xạ giữa các biểu diễn khác nhau.

XML không phải là một công nghệ tuần tự hóa, nó là một bộ thông tin mục đích chung.

Ở đây, chúng tôi sử dụng nó để trao đổi dữ liệu giữa các hệ thống khác nhau được thực hiện bởi các nhà cung cấp khác nhau với các đại diện nội bộ khác nhau. Chúng tôi xây dựng một hệ thống chuyển đổi / trao đổi XML để đưa dữ liệu qua lại. Nó hoạt động tốt cho điều đó.

XML vốn không tệ, nhưng tôi thừa nhận rằng việc thiết kế một giải pháp "tốt" bằng cách sử dụng XML không phải là chuyện nhỏ.

"Bản chất của XML là đây: vấn đề mà nó giải quyết không khó và nó không giải quyết được vấn đề tốt." - Phil Wadler, POPL 2003

Ý kiến ​​cá nhân của tôi là miễn là bạn không quan tâm đến việc xác thực, lược đồ, XSLT và các công cụ xấu xí còn lại và bạn giữ kích thước của các tệp nhỏ (nếu không phân tích cú pháp trở nên chậm), bạn có thể tìm thấy một số cách sử dụng XML tốt (một ví dụ là để cấu hình ứng dụng của bạn thay vì sử dụng các tệp INI).

Theo kinh nghiệm của tôi, mọi người chủ yếu phàn nàn về cách nó được sử dụng, chứ không phải bản thân công nghệ.

Các bit cồng kềnh và chậm mà mọi người phàn nàn thường là các thư viện / phương thức được sử dụng để lấy thông tin từ nó.

Tôi sử dụng nó để lưu trữ một lượng nhỏ thông tin có cấu trúc mà tôi muốn lưu trữ trên đĩa (không có cơ sở dữ liệu hoặc tuần tự hóa nhị phân) hoặc chuyển sang ứng dụng khác (về cơ bản cũng mô tả SOAP).

Nó tốt vì:

Đó là một "Giao diện" tiêu chuẩn mà nhiều hệ thống không đồng nhất có thể sử dụng để giao tiếp. Và có thể đọc được "Con người" (loại, hãy thử nhìn chằm chằm vào 5 MB XML)

Thật tệ vì:

Nó cồng kềnh, kích thước lớn hơn = băng thông nhiều hơn = nhiều $$

Có những lý do khác, mọi người đều có một sự kìm kẹp khác nhau ...

Giống như bất kỳ công nghệ nào khác: có nhiều công cụ và thư viện có sẵn.

Tôi không thích XML, đặc biệt là vì nó thú vị, khi mọi người nói rằng nó có thể đọc được, họ nói đùa, tôi nghĩ hoặc chưa bao giờ thực sự đọc một xml khi một người cố gắng nhúng xml vào một thuộc tính ... các thực thể xml làm cho nó thực sự không thể đọc được. Hơn nữa, thật đáng kinh ngạc khi có bao nhiêu không gian bị lãng phí vì thẻ kết thúc dư thừa và khả năng trộn văn bản và dữ liệu miễn phí ...

Nhưng:

• Xml có thể được chỉ định (xsd) và các công cụ có sẵn để kiểm tra sự phù hợp của dữ liệu Xml
• rất nhiều công cụ (trình soạn thảo văn bản và tương tự) hỗ trợ Xml
• rất nhiều thư viện (về mọi ngôn ngữ lập trình) hỗ trợ Xml

Nó cũng có lợi thế của sự ưu tiên, hầu hết các lần. Khi bạn đã cung cấp dịch vụ web bằng Xml và người ta yêu cầu dịch vụ mới ... có thể nó sẽ được thực hiện trong Xml vì đó là những gì bạn biết.

XML là một lựa chọn kém cho các tệp phải được duy trì bởi con người. Không có sự tách biệt trực quan giữa đánh dấu và nội dung, làm cho nó khó đọc. Thật tẻ nhạt khi viết chính xác mà không có trình soạn thảo có mục đích đặc biệt. Bất kỳ lỗi nào trong tài liệu XML đều gây tử vong; một tài liệu XML không thể được xử lý một phần. Khi một tệp XML không hợp lệ, thông báo lỗi kết quả thường không có ích.

Đối với bất kỳ tệp nào phải được duy trì bởi con người, tôi muốn sử dụng bất kỳ JSON, YAML hoặc mã nguồn nào trong một số ngôn ngữ được dịch (Python, Ruby, Groovy, v.v.). Chúng tôi đã thấy rằng một cách tuyệt vời để tạo cấu hình XML cho mã kế thừa là sử dụng Groovy MarkupBuilder. Một lựa chọn tốt khác là tạo một ngôn ngữ dành riêng cho tên miền; điều này khá dễ thực hiện với Ruby, Groovy và nhiều ngôn ngữ khác.

Phân tích cú pháp tương đối dễ dàng trong khi con người có thể đọc được cùng một lúc.

Và một số trình phân tích cú pháp đẹp (Ví dụ: Xerces {c ++}) có sẵn.