Относительно новинок к JavaScript, поэтому задайтесь вопросом, что лучше всего подходит для выполнения нижеописанного требования. Я хотел создать объект JSON (объект запроса RPC) и должен обеспечить некоторую структуру. Как я узнал, JS является динамическим языком, поэтому я могу добавлять любой тип объекта в любое время. Но мне нравится определять класс, который я могу заполнить, чтобы построить запрос JSON.Класс Javascript для обеспечения структуры JSON
var RecReq = {
ID:{},
HeaderLevel:{},
Content:{} //Content object goes here
},
HeaderLevel = {
HeaderID:{},
Note:{}
},
Content = {
Item: [] //Array of Item goes here
},
Item = {
IDs:[]
};
function ReceiveObj() {
this.RecReq = RecReq,
this.HeaderLevel = HeaderLevel,
this.Content = Content,
this.Item = Item
};
return new ReceiveObj();
Я уверен, что многие вещи не соответствуют вышеуказанному коду. Я не думаю, что объект создается с инициализированными массивами. На возвращенном объекте я не могу выполнить операцию push()
, чтобы вставить iten на Content.
Как вы подходите к этому. Вы создаете объект «на лету» или лучше определяете объект, который обеспечивает определенную структуру.
Я бы не стал создавать класс JS только для JSON DTO. Чаще всего вы отправляете DTO в какой-либо веб-сервис; если служба реализована на статически типизированном языке, пусть она заботится о безопасности типа. Другой подход, более подходящий для динамического языка, будет проверять структуру объектов, которые ваш код производит с помощью модульных тестов. – millimoose
благодарим вас за обмен опытом. Я не буду создавать класс, но создаю объект на лету. Мое намерение состояло только в том, чтобы DOCUMENT, что весь объект «может» содержать, чтобы он не вызывал ошибку на бэкэнд. Чтобы помочь моему обучению, можете ли вы предложить, как я должен был построить DTO (по идиоматическому пути JS). Если все это должно быть в одном классе или в том, как я пытался это сделать (другая переменная указывает разные поля/типы в классе). Это кажется ужасно неправильным, поэтому пример поможет мне подумать о JS. Еще раз спасибо – bsr
Чтобы документировать вещи, вы можете использовать определение на стороне сервера - если конечная точка реализована с использованием, скажем, .NET и WCF, это будет контракт с данными. (Это хороший вариант, если служба не является своего рода публичным API.) В противном случае вы можете посмотреть, как документируются основные библиотеки Javascript, которые используют шаблон «options hash»; обычно это означает «много-много примеров, описывающих фактические варианты использования». Поэтому я бы сказал, что вы не ошибетесь, просто предоставляя полный пример JSON, ожидаемого вашим сервисом, а затем документируете назначение атрибутов. – millimoose