Lưu trữ dữ liệu cấu hình (json)

Question

tl; dr Tại sao lưu trữ dữ liệu cấu hình trong tệp json được coi là tiêu chuẩn thực tế?

Gần đây tôi đã đọc một số phần của sách Maintainable Javascript, đặc biệt là Lưu trữ dữ liệu cấu hình.

Đây là trích dẫn từ chương:

Cấu hình dữ liệu được bảo quản tốt nhất trong một tập tin riêng biệt để tạo ra một tách sạch giữa nó và logic ứng dụng. Điểm khởi đầu tốt là có tệp JavaScript riêng cho dữ liệu cấu hình. Khi dữ liệu cấu hình nằm trong một tệp riêng biệt, dữ liệu này sẽ mở ra thêm khả năng quản lý dữ liệu đó. Một tùy chọn đáng giá là di chuyển cấu hình của bạn dữ liệu vào một tệp không phải là JavaScript.

Mặc dù bạn đang viết một ứng dụng JavaScript, JavaScript không phải là cách tuyệt vời để lưu trữ dữ liệu cấu hình. Đó là bởi vì cú pháp vẫn là ngôn ngữ lập trình, nên bạn cần chắc chắn rằng bạn chưa đưa ra lỗi cú pháp.

Ông về cơ bản nói rằng lưu trữ dữ liệu cấu hình trong tệp .json hoặc tệp .js là một thực hành không tốt và nên tránh.

Từ json.org:

JSON (JavaScript Object Notation) là một định dạng dữ liệu trao đổi nhẹ.

Trao đổi có nghĩa là để tôi gửi và nhận dữ liệu, để truyền đạt hai quy trình theo cách được định dạng tốt.

Rất nhiều người đang lưu trữ dữ liệu trong file json, có thêm rất nhiều tiếng ồn: dấu ngoặc nhọn, thụt đầu dòng, dấu ngoặc kép, dấu phẩy, không thể viết ý kiến, vv

Java sử dụng dây chuyền giá trị khóa, có cách nào đơn giản hơn để lưu trữ dữ liệu này không?

a 1 

Và với định dạng json (1):

{ 
    "a": 1 
} 

Và với định dạng js (2):

module.exports = { 
    a: 1 
} 

Microsoft thích sử dụng .ini file mà thêm phần để những chìa khóa các dòng giá trị.

Tệp cấu hình Unix cũng sử dụng các dòng khóa-giá trị. Sau đó, nếu tất cả thế giới sử dụng các dòng khóa-giá trị vì chúng dễ đọc/ghi bởi con người, tại sao các tệp json lại là một tiêu chuẩn thực tế trong thế giới node.js? Xin vui lòng không cho tôi biết đó là bởi vì json và javascript là từ đồng nghĩa thực tế và bởi vì các nhà phát triển quá lười biếng và thích gọi require("./config.json").

Trong các ví dụ trên, tùy chọn đầu tiên (1) được sinh ra để giảm bớt khả năng thay đổi dữ liệu.Và thứ hai, imo, nó chỉ là xấu. Điều này giống như lưu trữ dữ liệu cấu hình trong một lớp Java. Nếu tôi muốn đọc tập tin này từ php bởi vì tôi có một máy chủ apache và nodejs cho những thứ thời gian thực, làm thế nào tôi phải phân tích cú pháp tập tin đó? Tôi cần một trình phân tích cú pháp javascript.

Cả hai tùy chọn đều không có lỗi cú pháp hoặc chương trình có thể gặp sự cố.

Answer 1

PS - IMHO bạn là đúng về ý kiến, đó là khủng khiếp để làm việc với các định dạng mà không bình luận

PPS - Tôi phát triển Javascript, về bưu chính là javascript thẻ - vì vậy trả lời subjectivelly từ bên này

Tại sao lưu trữ dữ liệu cấu hình trong JSON?

Rất đơn giản. Trong Javascript. Vì JSON được định dạng là Object trong JS nên bạn có thể có cùng một cú pháp cho các đối tượng phía máy chủ, đối tượng phía máy khách và cửa hàng dữ liệu. Khi bạn muốn gỡ lỗi một cái gì đó, bạn có thể chỉ cần lấy toàn bộ JSON và đưa vào mã của bạn như var obj = JSON và nó hoạt động. Bạn có thể tìm thấy nhiều hơn trên trang web của http://www.json.org/ của Crockford.

Tại sao điều quan trọng là "rất nhiều tiếng ồn như dấu ngoặc nhọn, nhận dạng, dấu ngoặc kép .."?

Lý do đầu tiên là, tất nhiên, phát hiện lỗi cú pháp. Nếu bạn có cú pháp mạnh thay vì "giá trị khóa/cặp thuần", bạn có thể phát hiện dấu chấm phẩy hoặc dấu ngoặc nhọn nhanh hơn và dễ dàng hơn nhiều. Ngoài ra điều rất quan trọng - việc phân tích các tệp lớn là nhanh hơn.

Lý do thứ hai là cú pháp khác nhau cho mảng, đối tượng, chuỗi và boolean. Bạn muốn có tùy chọn chuỗi "true", boolean true và number true - 1, vì bạn muốn làm việc với nhiều cơ sở dữ liệu, kho lưu trữ, API, ngôn ngữ lập trình - bạn cần phải hỗ trợ toàn bộ quy mô.

Nhận dạng và mối quan hệ JSON không phải là một vấn đề. JSON có thể là một hàng. Trong các tập tin cấu hình nó khá không thực tế (người dùng stackoverflow có thể phân tích nó; DDD nhưng "con người bình thường" không).

Lý do thứ ba là mối quan hệ cha-con. Hãy có một mẫu:

[ 
    { 
     "email": "samuel@dude.com", 
     "isAdmin" : true, 
     "password": "KMLA#SLDOPW#", 
     "modules" : [ "html", "js", "css" ], 
     "creditcard" : { 
      "number" : 3288942398329832, 
      "expiration" : "2011-07-14T19:43:37+0100" 
     } 
    }, 
    { 
     "email": "bill@dude.com", 
     "isAdmin" : true, 
     "password": "KMLA#SLDOPW#", 
     "modules" : [ "js", "nodejs" ], 
     "creditcard" : { 
      "number" : 20432943092423, 
      "expiration" : "2011-07-14T19:43:37+0100" 
     } 
    }, 
    { 
     "email": "thomas@dude.com", 
     "isAdmin" : false, 
     "password": "KMLA#SLDOPW#", 
     "modules" : [ "ruby", "python", "css" ], 
     "creditcard" : { 
      "number" : 4239093223423, 
      "expiration" : "2011-07-14T19:43:37+0100" 
     } 
    } 
] 

.. bạn có muốn đăng nhập tất cả email vào bảng điều khiển không?
jsonobj.forEach(function(ele){ console.log(ele.email); });

.. bạn có muốn có quyền truy cập vào số thẻ tín dụng của người dùng đầu tiên không?
jsonobj[0].creditcard.number

.. bạn có muốn thêm người dùng tiếp theo không? jsonobj.push({ email: "peter@dude.com:, isAdmin: false })

.. bạn có muốn phân tích cú pháp tệp không có thư viện bên ngoài không? JSON.parse(jsonrawfile);

JSON so vớiXML

Cách rất mô phỏng là có XML. Nhưng về điều này hãy thử google một số khác biệt. Tôi nghĩ rằng các nhà phát triển front-end là người hâm mộ XML như người hâm mộ IE6. Có nhiều lý do tại sao nó như thế. Hãy thử google cho nó.

Hy vọng rằng điều đó khá hữu ích.