Missing Features in Entity Framework Core
Here’s a brief summary of some of the features that were present in previous versions of Entity Framework (6.x) and were excluded (or are not yet implemented) in Entity Framework Core 2.0: 

ASP.NET Core provides better support for clean, testable, maintainable architectures than any of its predecessors. Learn the underlying principles that apply to project/solution organization, how best to arrange your projects to support clean code, and how to refactor existing solutions toward this architecture. Examples will use ASP.NET Core but the principles covered apply to all languages and platforms.  

Oracle is pleased to announce that Oracle database support for Entity Framework Core 7 (EF7) is now available. Download Oracle EF7 for free from NuGet Gallery. 

Join us on November 8, for the launch of Visual Studio 2022. Learn about what's new, hear tips & tricks, participate in the live Q&As, and be the first to take the latest version for a spin. 

How you shouldn’t implement base classes

public class Entity<T>
{

  public T Id { get; protected set; }

}

Motivation for such code it pretty clear: you have a base class that can be reused across multiple projects. For instance, if there is a web application with GUID Id columns in the database and a desktop app with integer Ids, it might seem a good idea to have the same class for both of them. In fact, this approach introduces accidental complexity because of premature generalization. 

There is no need in using a single base entity class for more than one project or bounded context. Each domain has its unique path, so let it grow independently. Just copy and paste the base entity class to a new project and specify the exact type that will be used for the Id property. 

At last, SQL Server has caught up with other RDBMSs by providing a useful measure of JSON-support. It is a useful start, even though it is nothing like as comprehensive as the existing XML support. For many applications, what is provided will be sufficient. Robert Sheldon describes what is there and what isn't. 

For many years now I’ve advocated not using the repository pattern on top of an ORM such as Entity Framework. There are many reasons why that I’ll try and cover throughout this post based on ways that I’ve seen it implemented. Meaning, this post is talking about poorly implemented approaches or pitfalls that I’ve seen. 

try
{
    // some code to check  ...
}
catch (InvalidOperationException ex)
{
    // do your handling for invalid operation ...
}
catch (IOException ex)
{
    // do your handling for IO error ...
}

 catch (SomeException ex) when (someConditionIsMet)
{
    // Your handler logic
}

 catch (SomeDependencyException ex) when (condition1 && condition2)
{
 
}
catch (SomeDependencyException ex) when (condition1)
{
 
}
catch (SomeDependencyException ex)
{
 
}

 catch (SomeDependencyException ex)
{
 
}
catch (SomeDependencyException ex) when (condition1 && condition2)
{
 
}
catch (SomeDependencyException ex) when (condition1)
{
 
}

 try
{
    DoSomethingThatMightFail(s);
}
catch (Exception ex) when (Log(ex, "An error occurred"))
{
    // this catch block will never be reached
}

...

static bool Log(Exception ex, string message, params object[] args)
{
   Debug.Print(message, args);
   return false;
}

try
{
    var request = WebRequest.Create("http://www.google.coom/");
    var response = request.GetResponse();
}
catch (WebException we)
{
    if (we.Status == WebExceptionStatus.NameResolutionFailure)
    {
        //handle DNS error
        return;
    }
    if (we.Status == WebExceptionStatus.ConnectFailure)
    {
        //handle connection error
        return;
    }
 
    throw;
}

try
{
    var request = WebRequest.Create("http://www.google.coom/");
    var response = request.GetResponse();
}
catch (WebException we) when (we.Status == WebExceptionStatus.NameResolutionFailure)
{
    //Handle NameResolutionFailure Separately
}
catch (WebException we) when (we.Status == WebExceptionStatus.ConnectFailure)
{
    //Handle ConnectFailure Separately
}

Here’s what’s new in this preview release:

• Native dependencies support for Blazor WebAssembly apps
• Minimal API updates 

What’s new?

Here’s a sampling of the great new features and improvements in ASP.NET Core for .NET 7:

• Servers and runtime
  • Rating limiting: Limit the rate of handled requests using flexible endpoint configuration and policies.
  • Output caching: Configure output caching to reduce to more efficiently handle request.
  • Request decompression: Accept requests with compressed content.
  • HTTP/3: Built-in support for HTTP/3, the latest HTTP version based on the new QUIC multiplexed transport protocol.
  • WebSockets over HTTP/2: Use WebSockets over HTTP/2 connections.
  • WebTransport (experimental): Create streams and data grams over HTTP/3 with experimental support for WebTransport.
• Minimal APIs
  • Endpoint filters: Use endpoint filters to run cross-cutting code before or after a route handler.
  • Typed results: Return strongly typed results from minimal APIs.
  • Route groups: Organize groups of endpoints with a common prefix
• gRPC
  • JSON transcoding: Expand the reach of your gRPC services by also exposing them as JSON-based APIs
  • OpenAPI with JSON transcoding (experimenal): Use experimental support for generating OpenAPI specs for your gRPC JSON transcoded services.
  • gRPC health checks: Report and check the health of gRPC server apps.
  • gRPC client AddCallCredentials : Create clients that send authorized requests using bearer tokens.
• SignalR
  • Client results: Return client results to the server in response to requests from the server.
• MVC
  • Nullable view and page models: Nullable page and view models are now supported to improve the experience when using null state checking.
• Blazor
  • Custom elements: Build standard HTML custom elements with Blazor to integrate Blazor components with any JavaScript-based app.
  • Handle location changing events: Intercept location changing events to create custom user experiences when navigating.
  • Bind after/get/set modifiers: Run async logic after data binding and independently control how data binding gets and sets the data.
  • Dynamic authentication requests: Create dynamic authentication requests at runtime with custom parameters to handle advanced authentication scenarios in Blazor WebAssembly apps.
  • Improved JavaScript interop on WebAssembly: Optimize JavaScript interop call when running on WebAssembly using the new [JSImport]/[JSExport] support.
  • WebAssembly SIMD & exception handling: Improve performance with .NET WebAssembly ahead-of-time (AOT) compilation using WebAssembly SIMD and exception handling support.