视图模型->模型：谁负责持久性逻辑？
在我的 ASP MVC 2 应用程序中，我遵循具有特定视图模型的强类型视图模式。
我的应用程序视图模型负责模型和视图模型之间的转换。
我的视图模型我有一个静态ToViewModel(.. .) 函数，为相应的模型创建一个新的视图模型。到目前为止我对此很满意。
当我想要编辑模型时，我通过网络发送创建的视图模型并将更改应用回模型。为此，我使用静态 ToModel(...) 方法（也在视图模型中声明）。这里是澄清的存根：
public class UserViewModel
{
...
public static void ToViewModel(User user, UserViewModel userViewModel)
{
...
}
public static void toModel(User user, UserViewModel userViewModel)
{
???
}
}
所以，现在我的“问题”： 有些模型很复杂（不仅仅是字符串、整数……）。因此，持久性逻辑必须放在某处。
（对于持久性逻辑，我的意思是决策 是否创建一个新的数据库条目，...不仅仅是粗略的 CRUD - 我为此使用存储库）
我认为将它放在我的存储库中不是一个好主意，作为存储库（在我的存储库中）理解）不应该关心来自视图的东西。
我考虑过将其放入 ToModel(...) 方法中，但我不确定这是否是正确的方法。
你能给我一个提示吗？
LG
瓦拉帕
in my ASP MVC 2 application I follow the strongly typed view pattern with specific viewmodels.
Im my application viewmodels are responsible for converting between models and viewmodels.
My viewmodels I have a static ToViewModel(...) function which creates a new viewmodel for the corresponding model. So far I'm fine with that.
When want I edit a model, I send the created viewmodel over the wire and apply the changes to back to the model. For this purpose I use a static ToModel(...) method (also declared in the view model). Here the stubs for clarification:
public class UserViewModel
{
...
public static void ToViewModel(User user, UserViewModel userViewModel)
{
...
}
public static void toModel(User user, UserViewModel userViewModel)
{
???
}
}
So, now my "Problem":
Some models are complex (more than just strings, ints,...). So persistence logic has to be put somewhere.
(With persistence logic I mean the decisions wheater to create a new DB entry or not,... not just rough CRUD - I use repositories for that)
I don't think it's a good idea to put it in my repositories, as repositories (in my understanding) should not be concerned with something that comes from the view.
I thought about putting it in the ToModel(...) method but I'm not sure if thats the right approach.
Can you give me a hint?
Lg
warappa
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
Warappa - 我们也使用存储库模式和视图模型。
但是，我们有两个附加层：
服务层处理诸如持久关系数据（复杂对象模型）等内容。任务层处理数据的奇特 linq 关联以及任何额外的操作为向视图模型呈现正确的数据所必需的。
除了这个范围之外，我们每个实体还有一个“过滤器”类。这使我们能够在需要时针对每个类的扩展方法。
简单...:)
Warappa - we use both a repository pattern and viewmodels as well.
However, we have two additonal layers:
The service layer deals with stuff like persisting relational data (complex object models) etc. The task layer deals with fancy linq correlations of the data and any extra manipulation that's required in order to present the correct data to the viewmodel.
Outwith the scope of this, we also have a 'filters' class per entity. This allows us to target extension methods per class where required.
simples... :)
在我们的 MVC 项目中，我们有一个单独的转换器位置。
我们有两种类型的转换器，一个 IConverter 和一个 ITwoWayConverter（比这多一点，但我保持简单）。
ITwoWayConverter 包含两个主要方法 ConvertTo 和 ConvertFrom，它们包含将模型转换为视图模型的逻辑，反之亦然。
通过这种方式，您可以创建特定的转换器以在类型之间进行切换，例如：
然后我们根据需要将相关转换器注入到我们的控制器中。
这意味着从一种类型到另一种类型的转换不受单个转换器（存储在模型内部或任何位置）的限制。
In our MVC projects we have a seperate location for Converters.
We have two types of converter, an IConverter and an ITwoWayConverter (a bit more too it than that but I'm keeping it simple).
The ITwoWayConverter contains two primary methods ConvertTo and ConvertFrom which contain the logic for converting a model to a view model and visa versa.
This way you can create specific converts for switching between types such as:
We then inject the relevant converters into our controller as needed.
This means that your conversion from one type to another is not limited by a single converter (stored inside the model or wherever).