爲什麼灰燼模型與其他事物不同？

Question

在Ember中，所有內容都以其名稱的一部分進行註冊。即：

App.FoobarController 
App.FoobarView 
App.FoobarRoute 

不包括Ember-Data模型，它們全部只由它們的根名稱調用。即

App.User 
App.Post 
App.Comment 

爲什麼燼的數據模型打破這種格局，而不是被調用，分別App.UserModelApp.PostModel，App.CommentModel？

我意識到，我可以說出我的模型什麼是我想要的，但如果我繼續前進，名字我的用戶模型App.UserModel，那麼我所有的AJAX請求被髮送到/user_models和期望響應JSON與user_model/user_models根元素。我也意識到可以註冊別名/複數來使這種模式成爲可能。

但是，我可以做類似controllerName: 'Foobar'和templateName: 'Foobar'的事情，Ember自動將它們分別解析爲FoobarController和FoobarTemplate。我還可以定義App.FoobarView和App.FoobarController，Ember知道他們會一起自動配對。也就是說，我預計在將UserModel的AJAX請求重寫爲/users並通過App.store.find('User', 123)啓用提取時，會發生相同類型的魔術。

在處理模型時這種約定是否被破壞或者這只是對Ember-Data的監督/錯誤/不一致？

Answer 1

是否有這個約定在處理模型時被破壞的原因，還是這只是對Ember-Data的監督/錯誤/不一致？

我覺得這個約定並沒有被破壞，因爲它與你所期望的不同。在許多方面，ember正在建立在rails和其他MVC框架所使用的約定之上。通常，MVC應用程序圍繞代表域模型的一組對象構建。例如：

User, Post, Comment, etc. 

現在，每一個模型中，有可能需要的其他特定架構的對象，如：

UserController, UserView, UserPresenter, UserMailer, UserTemplate, UserView 

因此該約定的usermodel就沒有意義。我可以看到UserModel會更清楚，但會建議選擇你的戰鬥。試圖對抗框架（無論是燼，鐵軌還是其他）並使用自己的命名約定會導致大量額外的工作。除非你有錢可以燃燒或者有一個很好的理由，否則會推薦使用默認值。