asp.net mvc 模型与实体框架模型
在 asp.net mvc - model 文件夹中创建模型是最佳实践吗？ 将这些模型与您的视图结合使用，并使用服务层将我的模型“调整”为 EF 模型。
或者您是否使用过其他方法。这种方法的问题是，大多数时候我的（自制）模型是 EF 模型的副本（不是干的）
所以有人可以解释一下在你的视图中使用什么模型，因为它变得非常混乱。 model / viewmodel / Entityframeworkmodel ....
解决方案：
感谢您的回答，所有猜测我现在正在重构一些东西！
Would it be best practice to create a model in your asp.net mvc - model folder.
Use these models with your views and by using a service layer to "adapt" my model to the EF-model.
Or have you used another approach. The problem with this approachs is that most of the times my (selfmade)model is a copy of the EF-model (not dry)
So can someone explain me what models to use with your view cause it is becomming very confusing. model / viewmodel / Entityframeworkmodel ....
Solution :
Thanks for answers all guess i am at the moment to refactor some things!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
正确的方法是为 ViewModel 使用不同的类，并为持久性（实体）使用不同的类。通常的原因是您经常需要向视图发送一些附加数据（例如填充下拉列表的数据、禁用某些字段的数据等）、使用不同的验证或仅显示实体的子集。
我不是纯粹主义者。如果我发现我的视图模型与实体完全相同，我会直接使用该实体，但一旦我需要视图中的任何其他信息，我将重构代码。大多数情况下，由于增量开发，我从实体开始，以视图模型结束。
The correct approach is using different class for ViewModel and different for a persistance (entity). The usual reason is that you often need to send some additional data to a view (for example data to fill drop downs, data to disable some fields etc.), use different validation or show only subset of an entity.
I'm not purist. If I see that my view model is exactly the same as the entity I use the entity directly but I will refactor the code once I need any additional information in the view. Most often I start with entities and I end with view models because of incremental development.
通常，我的视图模型位于模型文件夹中，域模型位于 ORM 层中。
视图模型（从名称来看）是那些仅需要帮助查看过程的对象的普通模型，它们没有任何持久性，并且可能包含一些逻辑。
如果您面临域模型与视图模型匹配的问题，那么您可能需要重新设计模型，或者仅使用域模型而无需中间人。
Usually I have my View Models in the Models folder, and my Domain Models in the ORM Layer.
View Models (from the name) are normal models for those objects you need only to aid the viewing process, they have no persistence whatsoever and they may contain some logic.
If you face the issue that your Domain Models match your View Models then you may need to re-design the models OR just use the Domain Models without a man-in-the-middle.
对我来说，我更喜欢删除标准 MVC 结构中的 Models 文件夹，并添加存储所有视图模型的 ViewModels 文件夹。正如拉迪斯拉夫（Ladislav）在第一次迭代中提到的那样，这些视图模型可能是域模型中实体的精确副本，但随着时间的推移，它们会增长并且会有很大差异。
As for me I prefer deleting the Models folder in standard MVC structure and adding ViewModels folder where I store all the view models. As Ladislav mentioned at first iterations those viewmodels might be an exact copy of the entity from your Domain model but incrementaly they will grow an will differ a lot.
好吧，这没有意义。我曾经为此苦苦挣扎，我认为你需要有一个不是表实体的模型，我称之为域模型。原因是有时如果你使用linq2sql，那么你必须处理桥接/链接表（这不是真正的实体），以及复杂的计算，所以你不能把它放在你的表实体中，对吧？所以我的方法是让 ViewModel <->型号<->实体
Well, it does not make sense. I used to struggling with this,I think you need to have model which is not the table entity, I called this domain model. The reason for that is sometimes if you are using the linq2sql, then you have to deal with the bridging/link table (which is not the real entity), and complex calculation, so you can't make it in your table entity, right? So my approach is to have ViewModel <-> Model <-> Entity