DataModel、DataContract、ViewModel
我将有一个将连接到 WCF Web 服务的 asp.net MVC。该服务定义数据库连接。
我注意到我将有 3 个不同的模型/数据类。
首先是来自 MVC 的 ViewModel 人员。我想这可能与数据库中数据的表示方式有所不同。
其次是 DataModels，poco，它定义对象在数据库中的外观。
然后，DataContract 人员定义通过 WCF 服务传输的对象的外观。我猜它要么是 ViewModel 要么是 DataModel 的表示。
这是矫枉过正还是必要之恶？我应该将 DataContracts 定义为 ViewModel 人员，甚至是 DataModels。
您将如何做以及如何将其拆分为程序集？
I will have a asp.net MVC that will connect to a WCF webservice. That service defines the database connection.
I noticed I will have 3 different Model/data classes.
First off is the ViewModel guy from MVC. I guess it could be somewhat different from how data is represented in the DB.
Second is the DataModels, poco that define how the objects look in the database.
Then there is the DataContract guy that defines how the objects look that are transferred over the WCF service. Guess it will either be pretty much a representation of a ViewModel or a DataModel.
Is this a overkill or a necessary evil? Should I define the DataContracts as the ViewModel guys perhaps, or even the DataModels.
How would you do it and how would you split it into assemblies?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如您所提到的，我会将它们全部分开。它们每个都有不同的层来处理（即属于），并且应该是单独的对象来处理任何未来的更改。
wcf 项目将通过引用服务来创建，因此属于您的 wcf 服务。您的数据模型应该位于模型项目或数据访问项目中，而您的 ViewModel 应该位于 MVC 应用程序中，尽管如果您愿意，您可以从那里中断，但由于它与 MVC 应用程序的耦合相当紧密，因此值得商榷。
I would keep them all separate as you mentioned.Tthey each have a different layer to deal (ie belong to) with and should be separate objects to deal with any future changes.
The wcf items will be created by referencing the service so belong in your wcf service. Your data model should be in a model project or a data access project and your ViewModels in your MVC application although you could break then from there if you want but since it's a fairly tight coupling with the MVC app it's debatable.
当然不是。 ViewModel 是面向屏幕（用例）的。
但您可以在 SilverLight 或 jQuery 客户端使用的 DataService 中执行此操作。
这可能是有道理的。 POCO 的原因之一是它们甚至可以是同一类。
Certainly not. The ViewModels are screen (use-case) oriented.
But you might do this in a DataService that is consumed by a SilverLight or jQuery client.
That could make sense. And one of the reasons for POCOs is that they could even be the same classes.