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
Related
I'm doing a project with ASP.net core. I found that most of developers use Entity Framework for dealing with the database. I have worked with raw SQL queries with ASP.NET. I'm using SQL SERVER 2014 and have to develop a RESTfull API to deal with my database. My database consists of about 50 tables.
So my question is, what method is better for my task, using Entity Framework or using raw SQL queries?
From my research I have found that Entity Framework has basically two methods, Code first and Database first. I have looked into both methods. I need to know pros and cons of using entity framework compared to normal SQL queries.
And finally is there a effect on .net core with entity framework?
It seems that you have a large application, my recommendation is that you should use Entity Framework because you have LINQ. (Examples here: http://www.entityframeworktutorial.net/Querying-with-EDM.aspx).
With LINQ you can build your queries using methods instead of strings.
With LINQ:
var L2EQuery = context.Students.where(s => s.StudentName == "Bill");
With Native SQL:
var studentName = ctx.Students
.SqlQuery("Select studentid, studentname, standardId
from Student
where studentname='Bill'")
.FirstOrDefault<Student>();
Using entity framework with code first migrations and a decoupled from ef repository pattern architecture does not restrict you from using sql queries as well sometimes when you need to.
Your question will be closed because it is too opinion oriented.
But yes, personally, I greatly encourage the use of Entity Framework.
The thing is, if you have no experience at all in EF, then you will be subject to a learning curve. Which means it will still be easier for you to simply use SQL query in your code. That said, if you take your time and learn correctly how to use EF it will probably be of good use later.
I've experienced both Entity Framework and raw SQL queries, and now that i'm used to EF, I find it much better.
I am switching over to Symfony for a project that I am working on but I need a little advice on how to structure the files when it comes to models and using doctrine.
I have a custom framework that I use, which in turns uses the MVC model. Pretty much all of my MYSQL database queries are stored in the models and I access them through the controller.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
I have also generated a number of Entities that correspond to my MYSQL database. My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
I'm a little unsure how to structure this.
Thanks
Pretty much all of my MYSQL database queries are stored in the models
That's bad, but I'll mention about it later.
Now after looking at Symfony2, my interpretation is that "model" files in Symfony are called Servies. Is this correct?
Queries should be done in either repositories or in some cases in services.
If your query returns entities, then it should be repository for sure.
My question here is do I place my custom Doctrine queries inside the Service files or do I create them inside the Entity files?
Entities should be plain PHP objects. They shouldn't depend on anything than other entities. Entities actually doesn't even know anything about database. It's pure object oriented business logic.
Again, all DB queries should be in repositories or services.
I would suggest to go through Symfony Book in first place, to get idea of how "the Symfony way" works.
Symfony is not MVC framework:
Symfony2 is really about providing the tools for the Controller part, the View part, but not the Model part [...] Symfony2 is an HTTP framework; it is a Request/Response framework.
And it is great. Symfony allows to make your model as you wish without any restrictions. The Doctrine (ORM and/or DBAL) is a separate set of libraries. You can use any other library, or build your own persistence layer abstraction, or work with native SQL through PDO/MySQLi/etc.
Service is just an object that registered in the container and have some dependencies. Services can doing anything. They can represent your model, but it is not a requirement.
Organizing Your Business Logic (The Symfony Best Practices)
Doctrine ORM Best Practices
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.
Project Technology Stack:I am working for a project which is using Spring MVC. We are using JPA for ORM.
The sql database is MySQL.
Issue: The Business logic has become a lot complex in the application. To fetch data from the application, code is using a lot of Native SQL queries with multiple JOINS.
This creates a lot of problem while creating Integration test cases. This happens due to the fact that when entity is persisted using JPA's entity Manager the entity is in First Level Cache. Now when the next fetch query(which is written in native SQL) tries to fetch the data, it cannot. This happens because native sql queries always goto the database whereas the 1st Level Cache synchronises with the database after the whole test case has executed.
I wanted to know if there is a workaround for this?
I used to use DbContext for all of my DB Models, until I read Ways to optimize Entity Framework, after following the steps I found my self forced to switch to ObjectContext instead, So, There were alot of code changes to be done, but I am not sure that I doing the right thing, specially after Googling the deference I've noticed that DbContext is newer and better than ObjectContext, and also I noticed that I lost alot of things while switching to ObjectContext like "Migrations" and "Find" Method and much more...
So, Is the right thing to change my code to use ObjectContext instead of DbContext to increase the speed by Pre-Generating the Views ? or am I doing something wrong ?
You should not have to switch to ObjectContext to get pre-generated views. I created T4 templates for generating pre-generated views for CodeFirst. Take a look here: Entity Framework initialization is SLOW -- what can I do to bootstrap it faster?
The T4 templates are available on Visual Studio Gallerry. Here is the link to my blog post describing how to get and use them
I would encourage you to use DbContext as it is a simplified version of the ObjectContext. If the DbContext is not suffice, the wrapped ObjectContext can be accessed from the DbContext:
((IObjectContextAdapter)dbContext).ObjectContext
The "Generate Views" option is also available for Code First (DbContext) in EF Power Tools. Right-click a file derived from DbContext and select "Entity Framework" => "Generate Views". For more information see Generating Pre-compiled Views