I'm writing a business application using Entity Framework and there are some things that I need like:
transaction and transaction scope management **
data filtering
control over refreshing data from the db (eg. every 15 s)
be able to manage what changes are being made to the data and to be able to undo some of them
Those things aren't supported in any way by Entity Framework (or at least it's not easy to accomplish it).
Are there any libraries that sit on top of EF and can do that (or maybe they have their own ORMs) ?
Do I really have to implement that myself?
** I mean something like: I have an object and want to do some changes to it - I start a transaction and every change that is done from that point in time is included in the transaction, then I commit and that's all that gets commited to the db - other objects live their own happy lives.
Wouldn't any standard ORM do all that for you? Both Hibernate and SQLAlchemy (the big ones I've worked with so far) will do all that stuff for you. They both support transactions, versioning, filtering is straightforward and both support rollbacks during transactions.
For rapid business application development, have a look at Spring Roo, Entity Framework sounds like something that is not ready for the market, Spring is.
Quote from wikipedia: The first version of Entity Framework (EFv1) was included with .NET Framework 3.5 Service Pack 1 and Visual Studio 2008 Service Pack 1, released on 11 August 2008. This version has been widely criticized, even attracting a 'vote of no confidence' signed by several hundred developers.
Related
How can I scaffold EF Core directly from a Visual Studio SQL Server Database Project?
Solutions such as the following are preferred:
scaffold-dbcontext -connection "provider=ssdtproject, name=myprojectname.sqlproj"
scaffold-dbcontext -ddl "ssdtprojectoutput.sql"
scaffold-dbcontext -ssdtschema "ssdtproject.dacpac"
maintained-third-party-tool myprojectname.sqlproj -EfModelGenerationParameters
That's the whole question. What follows is my situation in more detail, so that you may be able to offer alternate solutions:
Although MS acknowledges EF Core is still not production-ready, it's also now 3-4 years since EF 6 progress ceased, and EF Core is the only LINQ code-similar path forward with NETCore compatibility. Thus begins the saga titled "So you're going to be using EF Core."
This part is opinionated, but to me (based on 25+ years of enterprise software design and development experience) Code-First is an absolute non-starter. It's fine for small week-one application concepts, but there's no reasonable pattern/process/practice that I can see to integrate constraints, views, etc. Without views designed-in, real business apps end up with devs repeating logic fundamentals in LINQ expressions all over the place, littering the code with static fields to support LINQ-to-SQL queries, confusing micro-combinatory patterns using LinqKit, etc. Without constraints we end up with ten times the defensive code requirements to handle runtime errors, rapidly blossoming unit and integration tests, and demo failures become the norm. Either our object-oriented experts need to become SQL experts or the converse, and we drastically increase the difficulty of finding and properly-compensating engineers. All of these issues I pointed out in a detailed conversation four years ago with Rowan Miller (who recently left the EF team, which doesn't bode well for near-term solutions).
Model-First (the visual .edmx designer in prior EF versions) is obviously off the table, since the MS solution to this was to claim Code-First really IS Model-First, and wash their hands of it. Consequently a truly neutral, let's call it "Contract-First" for clarity, approach doesn't exist in EF Core.
So, that rant (sorry, frustrated) brings me to Database-First, and thus Scaffold-DbContext. Our DB Schema is currently a revision-controlled Visual Studio SQL Server Database Project. Aside some known issues with this, it also seems ridiculous to have to take our DB schema (currently our single-point-of-truth), rebuild a live database from it, and then back-generate code from the live database, all as part of our build process just to verify database type alignment. I'd like instead to be able to simply detect changes and regenerate my DbContext and related Entities directly from the Database Project.
SSDT Database Projects seem to make Database-like objects available in many of the UIs where normally database connections are required. That makes me think it may be a short walk to use the database schema as a source for existing tools. For example, use a metadata provider in a connection string, make a simple modification to the EF Core code, etc.
SQL Sharpener "generate[s] at design-time using SQL files as the source-of-truth (such as those found in an SSDT project", and was recommended as a solution to this problem for previous versions of EF, but it does not support EF Core.
SQLite and SQL Server Compact Toolbox just added support for generating EF Models directly from .DACPAC, but it appears to depend on the EntityFramework Reverse POCO Code First Generator for that functionality, which prominently lists "Support EF Core" on its TODO List. The primary contributor of this project confirms that incompatibility.
Help?
I was struggling with the same until I ran into the sublime EF Core Power Tools extension for Visual Studio. Its reverse engineering tool sounds just like what you need.
https://marketplace.visualstudio.com/items?itemName=ErikEJ.EFCorePowerTools
There are Object Mappers for JPA support for NoSQL databases like Mongo, Couch in Hibernate OGM, Spring Data. But, I could not able to find any reliable and actively developed framework for Dynamodb.
I looked spring-data-dynamodb, but it is stated that:
Due to external time and project commitments, I'm no longer able to continue active development of this project as of January 2016. Thank you to everyone involved in shaping the project over the past few years and thanks to all those who have raised issues and submitted pull requests over the time.
This lack of support causes model integration problems with widely used Java MVC frameworks.
Could you please explain me the technical details, why there is not a complete Dynamodb Object Mapper for JPA support?
I want to evaluate the feasibility of writing a WCF service for my DevExpress XAF/Entity Framework Winforms application to use.
Dev Express suport for this question indicates that this would be quite difficult, because XAF uses dynamically-generated queries to select and modify data.
Never the less, I am wondering how to go about it.
I have thought of simply connecting to the remote database without having a middle tier, but the answer here makes me think that this would be unsatisfactory.
There is no problem with creating a WCF service with XAF. In fact DevExpress have documented the steps. The dynamically created queries are passed to the middle-tier for security checks and execution and the results are returned.
But as it stands, the middle tier functionality is in beta and does not support EntityFramework, only XPO (and it does not look like it's made it into 15.1 which will be released soon has just been released).
Note can also access the XAF middle tier data via OData. Again, only XPO for the time being.
OData's $metadata is based on EDM/CSDL, but with Entity Framework 7, EDMX is going away, replaced with code-first (or whatever they decide to call it).
This makes me wonder about using $metadata and the related CSDL spec, which might be at a dead end now. Do you have the same concerns or should I go head first into OData and enjoy its [maybe] short lived support from Microsoft.
OData v4 has just been published as a new OASIS standard, they're not going to drop support for it anytime soon.
The OData team have said that they have not even started working on K-Runtime version yet, I cant find the quote, but basically they mentioned that both the MVC6 and EF7 projects were evolving so rapidly that they were going to wait until things were stablized before implementing it, So it may be some time yet.
I've used "EF Provider Wrappers" made by Jarek Kowalski. It works fine but I noticed "Limitations and Disclaimers" section where it says:
The providers have not been extensively tested beyond what’s included in the sample code, so you should use them at your own risk.
As with any other sample, Microsoft is not offering any kind of support for it, but if you find bugs or have feature suggestions, please use this blog’s contact form and let me know about them.
I'm little confused here, Does Microsoft really expect developers to use EnityFramework on production websites without any official support (or recommendation) for 2nd level Caching?
There is no official 2nd level cache support. I'm even not sure if EF Provider wrappers are compatible with .NET 4.5. 2nd level cache is in backlog for future versions of EF.
You can also implement your own solution because EF is fully open sourced.
Btw. I have seen dozens of quite complex web sites running in production without any cache ...
There is now a 2nd level cache provider available for EF 6.x
Entity Framework does not currently support caching of query results. A sample EF Caching provider is available for Entity Framework version 5 and earlier but due to changes to the provider model this sample provider does not work with Entity Framework 6 and newer. This project is filling the gap by enabling caching of query results for Entity Framework 6.1 applications.
https://github.com/moozzyk/EFCache
And Redis provider implemented on top of it :
Extends EFCache by adding Redis support
I wanted to add L2 Cache to EF using Redis - there was nothing
available at the time.
I found EFCache written by Pawel Kadluczka (moozzyk) over on CodePlex
https://github.com/silentbobbert/EFCache.Redis
Apache Ignite.NET provides a distributed in-memory 2nd level cache for Entity Framework: https://apacheignite-net.readme.io/docs/entity-framework-second-level-cache