Strange behaviour with StructureMap / ASP.MVC / Visual Studio / LinqToSql

强颜欢笑 提交于 2019-11-29 07:42:52

I was talking to Jeremy Miller about this and you don't want to manage the lifetime of the db context with SM - let the repo instantiate as needed. This presents problems with how you will do object updating/persistence (if you're relying on a context staying alive for more than one request) but it's worth it to not rely on this for a web app.

I had to remove the db context management stuff from the storefront for a reason like this - I was getting memory leaks. I won't say it's SM's fault - but overall just let the repo open a new context.

One common mistake when using DI containers with ASP.NET MVC is that many DI containers default to a Singleton pattern. I don't know if that's the case here, but you should double check. ASP.NET MVC requires that the controller is created on every request because it has per-request state and context.

Add:

MultipleActiveResultSets=True

To the end of your connection string (assuming MSSQL 2005+)

To do this for your linq context: Open the properties tab -> Expand Connection -> Click the "..." on 'Connection String' -> 'Advanced' -> 'MultipleActiveResultSets' -> true.

I solved this one myself today and my architecture is almost identical (save for unity instead of structure map). Including the two controllers being loaded via JS!

Are you completely sure nothing along in the object hierarchy is being Cached / or has a lifetime config? I have a prod app with a config just like this:

    ForRequestedType<SomeDataContext>().TheDefault.Is.ConstructedBy(
        () => new SomeDataContext(someConnString);

It isn't using asp.net MVC. Regarding the scoping issue, if you haven't set up anything, structure map will default to PerRequest (not asp.net request but structure map request, like each .GetInstance call) - http://structuremap.sourceforge.net/Scoping.htm. If you are positive on no configuration to affect it, then look at whether the mvc contrib or something else might be reusing instances.


Regarding the exception info posted. The error involves a combination of action results, action result filters, json serialization, custom methods, and also one linq2sql call failing because of an unexpected null. That's a combination of many different pieces, some of which I don't know. I would play safer and move the calculate stuff (that calls into linq2sql) being called when doing serialization to somewhere else where the json serialization/action results pieces aren't involved. This is just a wild guess, as I don't know how/when those pieces are called and what type of actions they have internally.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!