发表新帖
发表新帖

Serializing Entity Framework problems

后端 未结
关注
5 1961
無奈伤痛
無奈伤痛 2020-12-16 05:15

Like several other people, I\'m having problems serializing Entity Framework objects, so that I can send the data over AJAX in a JSON format.

I\'ve got the following

5条回答
  • 隐瞒了意图╮
    隐瞒了意图╮ (楼主)
    2020-12-16 05:22

    I had a similar problem with pushing my view via Ajax to UI components.

    I also found and tried to use that code sample you provided. Some problems I had with that code:

    • SupportedTypes wasn't grabbing the types I needed, so the converter wasn't being called
    • If the maximum depth is hit, the serialization would be truncated
    • It threw out any other converters I had on the existing serializer by creating its own new JavaScriptSerializer

    Here are the fixes I implemented for those issues:

    Reusing the same serializer

    I simply reused the existing serializer that is passed into Serialize to solve this problem. This broke the depth hack though.

    Truncating on already-visited, rather than on depth

    Instead of truncating on depth, I created a HashSet of already seen instances (with a custom IEqualityComparer that checked reference equality). I simply didn't recurse if I found an instance I'd already seen. This is the same detection mechanism built into the JavaScriptSerializer itself, so worked quite well.

    The only problem with this solution is that the serialization output isn't very deterministic. The order of truncation is strongly dependent on the order that reflections finds the properties. You could solve this (with a perf hit) by sorting before recursing.

    SupportedTypes needed the right types

    My JavaScriptConverter couldn't live in the same assembly as my model. If you plan to reuse this converter code, you'll probably run into the same problem.

    To solve this I had to pre-traverse the object tree, keeping a HashSet of already seen types (to avoid my own infinite recursion), and pass that to the JavaScriptConverter before registering it.

    Looking back on my solution, I would now use code generation templates to create a list of the entity types. This would be much more foolproof (it uses simple iteration), and have much better perf since it would produce a list at compile time. I'd still pass this to the converter so it could be reused between models.

    My final solution

    I threw out that code and tried again :)

    I simply wrote code to project onto new types ("ViewModel" types - in your case, it would be service contract types) before doing my serialization. The intention of my code was made more explicit, it allowed me to serialize just the data I wanted, and it didn't have the potential of slipping in queries on accident (e.g. serializing my whole DB).

    My types were fairly simple, and I didn't need most of them for my view. I might look into AutoMapper to do some of this projection in the future.

    0 讨论(0)
     看不清?
    提交回复
    热议问题