I can find a lot of articles on how to enable DbContextPooling in ASP Net Core through AddDbContextPool function.
But what about .Net framework 4.7.2 when this is not available. How can I reuse the DbContext from the pool?
Thanks
AddDbContextPool sets up services in the dependency injection container to make it more efficient to get DbContext instances for each request.
If you are not using ASP.NET Core, but your application follows a similar model (e.g. DbContext instances are needed to process Web or service requests) and the number of requests per second is very large, then my first recommendation would be to setup DI using Microsoft.Extensions.DependencyInjection and create DI scopes per request like ASP.NET Core does. Once you do that, you should be able to call AddDbContextPool the same way you would do in an ASP.NET Core application, and resolve your DbContext using DI with all the benefits of DbContext pooling.
Besides that option, in theory you could do manually what AddDbContextPool achieves using DI.
For example, first create a singleton pool of type DbContextPool. Then, for every instance of YourDbContext you need, get a lease using pool.Lease, and then get the context using lease.Context.
You have to make sure that you dispose both the context and the lease when you are done using them.
Caveat: this approach requires direct usage of low level APIs that are in internal namespaces and that therefore could change or disappear in any future minor or major release of EF Core.
If your application doesn't work like that (for example, if it is not a web application or a web service that need to process large numbers of requests), then there is no advantage on using DbContext pooling.
Related
I created a .net 6 minimal API project with EF Core that uses DI to create repositories with Scoped lifetime. The API project uses mediatr to send the request to a proper handler. The handler's get injected with db repositories. This works when I run this project directly.
I am migrating that project to an AWS Lambda project using the new AWS .NET 6 Templates in the visual studio toolkit. For whatever reason, the exact same code that runs fine in the minimal API project now throws an error because the injected repositories dispose their connections before the end of the request.
This error occurs anytime I run a command against the database.
I believe this is happening because of a serialization error that occurs in entity framework core. This issue doesn't occur in my regular project because I'm guessing it's using a different serializer to handle the serialization of entities.
The errors being thrown are:
System.Text.Json.JsonException: A possible object cycle was detected. This can either be due to a cycle or if the object depth is larger than the maximum allowed depth of 32. Consider using ReferenceHandler.Preserve on JsonSerializerOptions to support cycles.
Cannot access a disposed context instance
If I update the Json Serializer that .net is using to handle cycles, then the 1st error turns into: "System.NotSupportedException: Serialization and deserialization of 'System.Type' instances are not supported".
This looks like some sort of conflict with Pomelo Entity Framework Core
and the way the .net 6 lambda templated project is setup.
EDIT:
After looking at this more, I think the issue is with whatever serialization library that AWS Lambda template project uses vs whatever serialization library is normally used by Pomelo to handle things.
Scenario: the application has a long running method to return the data and build the final entity of a slowly changing dimension. In the previous versions of .net the data could be setup for interception and caching with the CacheInterceptionBehavior while registering the Interface with Unity.
Is there a corresponding way to do something similar in .net core?
I am working in my Application Architecture and i am wondering if i should use WCF or not.
The UI will be a public website written in ASP.NET MVC 3 but in the future possible Iphone/Android applications...
So now i have a data layer (Entity framework + repository), business layer (Class library)
and UI (ASP.NET MVC) communicating via ViewModel.
I understand that in a good SOA application the business layer should be exposed as a webservice but i am wondering about performance issues, beacause my website traffic will be high and hosting the WCF and the website in IIS in the same machine is a waste of time and of performance since to communicate they have to serialize/deserialize objects.
Is keeping my business layer in a dll (class library) and deploy it in the ASP.NET application better then hoting it in a wcf service ?
Thanks for help.
http://geekswithblogs.net/BlackRabbitCoder/archive/2010/06/13/premature-optimization-and-performance-anxiety.aspx
I think that leaving things as just a dll for right now would be the simplest solution until you firm up your requirements for iphone/android solutions. We use WCF extensively where I work, and it can be very fast.
That said, creating a WCF service on the chance you might need it later seems premature and its always easy to add a web reference later and remove the dll. You can't get the hours spent on a WCF service back (and the risk of needlessly adding another layer between your app and its data) as easily.
After plenty of reading, I still don't understand Unity for MVC 3.
Specific points
Why use it? I can create a controller that in its constructor, it takes a new EF context for testing.
How? I keep seeing bits are parts, but is there an end to end walk through on implementing Unity on MVC 3 (Live)? There seem to be plenty on Beta and RC, but the code always seems to have a problem on live frameworks.
Currently this is not impacting my unit testing, since my controllers have overloaded constructors, as does my EF context.
If you have a small project, you may not benefit from IoC.
Lifetime management if a plus for me. I don't have to dispose a repository (or service layer) in every controller. It thins out my code and creates the object for me. In addition, I know I have a clean separation in case I ever need to change things. It almost forces me to. I use for example IRepository that is backed by entity framework. For testing I use a fake IRepository implementation. So sure, I could manually create it in my application but this leads to some bad practices in larger projects and I lose the benefits of having the interface.
I have a basic demo for a super short talk I did recently on this for (15 minutes) mvc and unity for dependency injection using the unity.mvc3 nuget package:
http://completedevelopment.blogspot.com/2011/12/using-dependency-injection-with-mvc.html
Btw. Dependency Injection in .Net - best book on the subject without a doubt.
It's very useful for wiring up all your dependencies, handling life cycle of your objects, error handling, transaction handling, testing purposes and ...
All of above point are advantages of using an IoC framework, but I strongly recommend using Ninject. it has a very friendly DSL for binding modules, has out of box library and extensions for ASP.NET MVC and is an open source lightweight DI framework.
It has also many extensions.
Spring mvc is a framework that has been long time out there, it is well documented and proven technology. A lot of web sites are using spring.
Seam is a framework based on jsf - rich faces implementation.
It has a lot of ajax based components.
It uses some heavy stuff like EJB, JPA.
All of this is prone to errors and this framework is so slow (at my computer it is almost impossible do develop something because it is really slow, especially redeploying on jboss)
But is is very good for back office applications.
Does someone have a professional experience with this two frameworks?
Can you recommend the better one ?
Why?
Regards
I use both: Spring-MVC (2.5) and Seam
Because Seam uses Java Server Faces Technology (A server-side based Technology), behind the scenes, It is better designed for small and medium applications. (Each JSF view Tree is stored on Session - You can store on client side, but be aware bandwidth issues). But it has some advantages:
Typically web application uses the following path
view >> controller >> service >> domain
With Seam, you can get
view >> service >> domain
Or even (by using mediator pattern provided by Seam Framework)
No controller, No service
view >> domain
Besides that,
JSF 2 supports JSR 303 - Bean Validation
You can use Wicket instead of JSF if you want
Conversation and Business process management support
Use can use Spring DI if you want
Spring-MVC
It has a powerful web-Tier infrastructure
Handler Mapping (It chooses which Controller should handle the request)
View resolver (It chooses which View should render the response)
It can be used for large applications
Powerful data-binding
Spring 3.0 supports Annotation-based Controller (JSR 303 - Bean Validation, coming soon)
But i still not use Spring 3.0 because
By using (and extending when needed) MultiActionController, i can get convention over configuration without no xml settings to define your Controller (You just need to set up your MultiActionController as #Component)
SimpleFormController provides similar behavior found in Spring 3.0 annotation based controller
...
About The learning path, i think both are similar.
I have worked professionally with Seam and it is a killer framework. It really boosts up your productivity. You can use POJOs instead of EJBs, if you think EJBs are slowing you down. About the deployment, just consider deploying to Tomcat instead of JBoss. On my machine redeployment in Tomcat is done in a couple of seconds. But I still haven't used Spring MVC to compare them.
We have been using Seam for a very large site using POJOS and communicated with web services or Hibernate deployed on Tomcat. We have found that the back button support does not work well or is prone to being specific to implementation patterns. Additionally, there is a tendency for sessions to grow very large if using server side state. Attempts to reduce the session size impact back button support or iframe usage due to reduce number of view states stored in session. More or less, our issue have all been performance related. The tomcat requires more memory and supports less users when compared to a struts 1.2 or spring mvc. We are using around 50 tomcats to support our userbase.
I have used both SEAM and Spring MVC for a few months.
I prefer Spring MVC to SEAM. BTW I noticed JBoss halted the SEAM3 development.
I found a interesting article about comparison of SEAM and Spring MVC.
The link is
http://java.dzone.com/articles/why-java-ee-lost-and-spring?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29&utm_content=Google+Reader
Thanks
I have used both Seam 3 and Spring 3 frameworks.While Seam 3 is easier to code and has a lot of features supporting session management and transaction management ,the performance is slow.Spring is much faster.