I have inherited an ASP.NET application, using Entity Framework 6, and have enabled migrations. In my Global.asax, I have this:
using (var context = new MyContext())
{
Database.SetInitializer(new MigrateDatabaseToLatestVersion<MyContext, MyConfiguration>());
context.Database.Initialize(true);
}
The problem is that every time my application needs to start up (due to IIS shutting it down for example), this logic is run, even though in most cases there is no migration to be performed. This significantly slows down the processing of the requests.
What are my options here? What is best practice? I could disable this and use the Package Manager Console to perform migrations manually, but that kind of beats the purpose (though if there are no other options, I'm prepared to do this).
The EF6 automatic migrations seem to introduce several issues (not only performance), so the EF Core team decided to remove them from EF Core (you can read some reasoning here).
Since EF Core is the EF6 successor (the future of the Entity Framework), looks like the recommendation (best practice) is to disable it and perform migrations manually.
Related
Please advise the modern architecture of ASP.NET WebApi application (better .NET Framework not Core) with the latest innovations. For example: Unit of work pattern, controller -> manager -> repository, Automapper, xUnit, Serilog or..., a reliable migration mechanism for Oracle - Liquibase or... Asynchronous execution - async / await.
Requirements: authentication - AD / Windows, DB - Oracle. If there are code examples it would be ideal
UPDATE 1
What about ORM and migration system. In my opinion code first approach and EF migrations is good because the model suit to DB copletely, but it is risky. Previously I made Database Project for MS Sql Server and all change scripts was generated by comparing schemas of original DB and DB changed by EF migration, like this:
create models
apply migration to local (dev) database
compare original DB and changed DB, ectract/generate change SQL scripts
create deployment migration for CI/CD (DB project, liquibase or similar)
rollback local DB and test deployment migration
commit and push
It looks strange, but practice shows that using EFs migrations leads to data loss
For me, an API (which your app exposes to consumers) can be thought of as just another type of presentation layer.
If you assume that's the case then any sensible .Net architecture would suit. Personally I follow an logical approach like this: 5 layer Architecture - https://morphological.files.wordpress.com/2011/08/5-layer-architecture-draft.pdf
Not sure if that answers your question though. I think if you get the logical architecture sorted out, then determining which technologies you use to implement isn't so hard.
The 5-Layer architecture referenced above uses dependency injection, so you can use whatever database technology you like.
Use of sync vs async depends on the nature of the actual functional and technical problems you're trying to solve.
I want to separate my ASP. NET MVC 5 + WebApi2 solution into separate logical projects, so (in my head) I have:
Data.csproj
references EF6 and handles Code First migrations
Models.csproj
references Automapper
refrences Data (above)
Services.csproj
references Models (above)
Web.csproj
references autofac
references services above
But I can't get my real project to look like that because
Identity sprinkles the model and EF references all over my Web.csproj
When I configure Autofac in Web.csproj and try to register my DbContexts and whatever other dependencies are in my other projects, I will need access to the concrete types, so Web will need to reference all other projects as the DI is setup in Web?
This is a brand new project auto-generated by the ASP .NET template. Thanks.
Generally, you avoid getting your Entity-Framework pollution into your web code by not referencing your data-models in your web project.
If you put interfaces for the models in a separate infrastructure project, for example, you won't have that problem any more. Your 'services' can return abstract types with no dependency on EF and coupling is reduced.
Personally, I like to get around this problem wither with a separate project that is responsible for factory code or (even better IMO) giving each project responsibility for constructing its own objects. Having the factory code in the same place further reduces coupling and can make refactoring easier.
One more thing...
If this is a new project, why do you even need a DI container. You could always use poor man's dependency injection and refactor later when you have a better idea of your needs. They are often overused or used as a crutch to hide overly complex lasagna code. It is an incredibly useful and powerful technology, but most of the benefit in terns of flexibility can also be realised through well designed factories and builders. These can have the additional benefit of increased readability.
I am wondering some point on deploying an Asp.NET MVC5 application to my own server.
What if it happens, if i add more attributes in one of my model class or add more model class. What should i do for not losing data.
Is there any other options shoul i need to perform other than asp.net mvc4 since i could not find any tutorial about deployin asp.net mvc5 with Identity.
What is the best efficient way to change my application view, controller and model on run-time. Can i working on my local PC while using the remote code file and database ?
Regards.
I have a hard time understanding your requirements but for the database part, I would recommend "entity framework migrations". It's made handling model changes locally and remotely.
http://msdn.microsoft.com/en-us/data/jj554735.aspx
I have worked with entity framework migrations a lot but sometimes if you make big changes, such as Foreign keys or enums, the migrations give a problem. I then started to use a tool from RedGate.com called "Sql Compare." Works better than Entity migrations - now I don't worry about data changes. Usually this will not lose data, but if it is going to lose data, it will warn you.
Best solution to losing data -make backups.
I'm currently working on a project that uses Entity framework for data persistence. It started using Entity Framework 4 with EDMX and T4 template and ObjectContext with Objectset.A lot of Complied queries have been used for improving the query performance.
However, the approach is not extensible anymore because project team size has increased and Test Driven development need to be implemented. So we took the decision to convert using entity object in to POCO and DbContext for the support of Test Driven Development for repository integration test with data migration.
Unfortunately, we have realized that there is no support for complied queries for DbContext.
We decided to use two separate inherited context classes from DbContext for (CRUD) and ObjectContext (Complied Queries), as in near future we can shift to auto compile query support with DbContext.
My Questions are
What are the consequences with can be occurred by implementing this approach ?
Is there any alternative approach ?
Thanks
I've created a business layer with a database model to be used in an ASP.NET application. I've used Linq To SQL Classes in Windows Forms before but using ORMs in per-request web applications is foreign to me. I've a few things I couldn't figure out and I'd appreciate if anyone give me any insight..
My BLL has static methods like GetRecord() or UpdateRecord(). Each one of these methods creates a new ObjectContext instance, destroyed after unit of work. I don't have any HttpContext.Current.Items cache implementation.
I'm using EF .NET 3.5.
I've created a pre-generated view (Model.View.cs) and added it to my solution. Is this all I have to do to use it? Also do I need to publish csdl, msl and ssdl files with my dll?
Is precompiling queries bad for ASP.NET applications? I have like only one or two queries for any ASPX page and very rarely a select query used twice in the same page. Will it slow down the application if precompile my queries? I wonder if a precompile made by Session A would be useful for Session B?
I've created the following method to update a record in ASP.NET page and I wonder if it is a good way to do it:
ASP.NET gets the record(Entity) using BLL.GetRecord()
Updates any values
Sends updated record to BLL.Update()
BLL.Update() checks if the record exists
Uses context.ApplyPropertyChanges() to update the record
I've red a few entity framework performance charts and in every one of those charts there are two different statistics for queries: first run and the second run. Since I work with unit-of-work type of design, will my queries never see second runs?
Thanks.
You need the CSDL, etc., either as files or resources. View pre-generation helps with performances, but doesn't relieve you of the need to include EDMX in some form.
No.
OK as far as it goes. Hard to say more without seeing code.
It depends. This post should help.