Saya kira itu hanya tergantung pada bagaimana Anda menggunakan kerangka kerja. Saya pribadi belum pernah menemukan kebutuhan ini, satu-satunya saat saya bisa membayangkan menginginkan ini adalah untuk serialisasi objek dan saya menggunakan ember-data, sehingga kebutuhan itu tidak relevan.

Yang mengatakan, jika saya memiliki masalah ini, saya akan mulai dengan menggunakan Ember.ObjectProxy dan melihat seberapa jauh itu membuat saya. Berikut ini contohnya: http://emberjs.jsbin.com/kapenomivu/1/edit?js ,output

fungsi generik yang mengulangi properti objek

inilah gunanya hasOwnProperty

jangan ragu untuk menggunakan, Ember.keys yang kurang lebih Object.keys

Ember.keys(Ember.Object.create({ foo: 1 }))
>  [ 'foo' ]

Yang mengatakan, jika saya memiliki masalah ini, saya akan mulai dengan menggunakan Ember.ObjectProxy dan melihat seberapa jauh itu membuat saya. Berikut ini contohnya: http://emberjs.jsbin.com/kapenomivu/1/edit?js ,output

Saya mungkin akan merekomendasikan hal ini, mengapa tidak menggunakan pojo secara langsung?

@stefanpenner Saya pikir itu benar-benar pertanyaan untuk OP. Saya kira saya berasumsi bahwa dia memiliki kelas yang menghitung properti/fungsi/pengamat/dll. Saya tidak mempertimbangkan hanya untuk mengulangi Ember.keys , saya pikir itu akan mencakup hal-hal dari kelas (saya bersumpah kembali pada hari itu), tetapi terkejut karena ternyata tidak.

Hanya karena penasaran, mengapa Anda menyarankan untuk tidak menggunakan Ember.ObjectProxy ?

Sunting: Hanya untuk memperjelas, solusi Ember.keys jauh lebih bersih dan mendapatkan suara saya. Hanya ingin tahu apakah Anda memiliki pikiran negatif khususnya di sekitar ObjectProxy .

Ada beberapa strategi untuk mengekstrak struktur "Hash" asli yang digunakan untuk membuat objek bara (dengan atau tanpa nilai yang dimodifikasi), pertanyaan saya sebagian besar tentang seberapa sering komunitas Ember.js umum membutuhkan ini. metode .nativeCopy akan sangat bagus pada Ember.Object tetapi saya menghargai kebutuhan untuk sangat selektif dengan penambahan API. Terkadang masuk akal untuk menambahkan metode yang membuat operasi yang sangat umum menjadi lebih nyaman dan terkadang tidak. Saya mendapatkan perasaan bahwa orang tidak mengalami kebutuhan ini sesering saya.

Salah satu contoh nyata, jika Anda penasaran, adalah menggunakan Ember.Object untuk mendukung formulir "Buat Baru [...]". Mungkin formulir buat tepat di bawah daftar item. Jika Anda menggunakan this.store.createRecord untuk membuat model kosong untuk mendukung formulir, itu segera menambahkan item baru ke daftar di atas dan mengisi nilai saat Anda mengisi formulir. Untuk menghindari ini, saya mungkin membuat Ember.Object untuk mendukung formulir, tetapi kemudian saya harus mengeluarkan nilainya satu per satu untuk diteruskan ke createRecord

Satu alasan terakhir saya sering melakukan ini adalah untuk membuat salinan yang dalam karena mengimplementasikan Ember.Copyable sangat merepotkan. Saya suka desain Ember.Copyable tetapi implementasi default/generik yang waras akan sangat bagus.

Alasan terbesar untuk membutuhkan pojo adalah untuk dukungan perpustakaan pihak ke-3. Datatables, jstree, dll. semuanya mengharapkan array dan objek javascript biasa dan akan meledak dengan struktur data ember.

@ccarterc seperti, misalnya localforage.setItem - ini adalah PITA dengan Ember.Object
Menghadapi itu hari ini dan harus menempatkan "pelarian" khusus untuk itu.

Berlari ke kebutuhan yang tepat hari ini. Seperti yang dikatakan @ccarterc , ini sangat penting untuk

Saya ingin kemampuan untuk bekerja dengan POJO, jadi saya bisa mengirim objek saya ke perpustakaan Vanilla JS pihak ke-3.

ya tolong - berjuang dengan ini sekarang untuk api pihak ke-3. solusi saya saat ini adalah melakukan getProperties untuk objek dengan array sekitar 70 bidang di atasnya. ini tampaknya konyol dan memiliki fungsi untuk melakukan itu akan sangat bagus ...