zoriya/EntityFrameworkCore.Projectables
1
0
Fork 0
mirror of https://github.com/zoriya/EntityFrameworkCore.Projectables.git synced 2026-05-25 03:53:18 +00:00
Code Issues Packages Projects Releases Wiki Activity

Fixed some typos

Browse Source
This commit is contained in:
Koen
2021-11-05 06:10:57 +08:00
committed by GitHub
parent 2621ec89d0
commit 065808b321
1 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README.md
+5 -5
View File
@@ -92,7 +92,7 @@ There is currently no support for overloaded methods. Each method name needs to
No; The runtime component injects itself within the EFCore query compilation pipeline and thus has no impact on the database provider used. Of course you're still limited to whatever your database provider can do.
#### Are there performance implications that I should be aware of?
There are 2 compatibility modes: Limited and Full. Most of the time, limited compatibility mode is sufficient however if you are running into issues with failed query compilation, then you may want to try Full compatibility mode. With Full compatibility mode, Each Query will first be expandend (Any calls to Projectable properties and methods will be replaced by their respsective Expresions) before being handed off to EFCore. (This is similar to how LinqKit/LinqExpander/Expressionify works). Because of this additional step, there is a small performance impact. Limited compatibility mode is smart about things and only expands the Query after it has been accepted by EF. The expanded query will then be stored in the Query Cache. With Limited compatibility you will likely see increased performance over EFCore without projectables. I have a planned post coming up talking about why that is but for now you can see it for yourself by running the included Benchmark.
There are 2 compatibility modes: Limited and Full. Most of the time, limited compatibility mode is sufficient however if you are running into issues with failed query compilation, then you may want to try Full compatibility mode. With Full compatibility mode, Each Query will first be expanded (Any calls to Projectable properties and methods will be replaced by their respective Expression) before being handed off to EFCore. (This is similar to how LinqKit/LinqExpander/Expressionify works). Because of this additional step, there is a small performance impact. Limited compatibility mode is smart about things and only expands the Query after it has been accepted by EF. The expanded query will then be stored in the Query Cache. With Limited compatibility you will likely see increased performance over EFCore without projectables. I have a planned post coming up talking about why that is but for now you can see it for yourself by running the included Benchmark.
#### Can I call additional properties and methods from my Projectable properties and methods?
Yes you can! Any projectable property/method can call into other properties and methods as long as those properties/methods are native to EFCore or as long as they are marked with a `Projectable` attribute.
@@ -103,7 +103,7 @@ Yes you can. It's perfectly acceptable to have the following code:
[Projectable]
public static int Squared(this int i) => i * i;
```
Any call to squared given any int will perfertly translate to SQL.
Any call to squared given any int will perfectly translate to SQL.
#### How do I deal with nullable properties
Expressions and Lamdas are different and not equal. Expressions can only express a subset of valid CSharp statements that are allowed in lambda's and arrow functions. One obvious limitation is the null-conditional operator. Consider the following example:
@@ -111,7 +111,7 @@ Expressions and Lamdas are different and not equal. Expressions can only express
[Projectable]
public static string? GetFullAddress(this User? user) => user?.Location?.AddressLine1 + " " + user?.Location.AddressLine2;
```
This is a perfectly valid arrow function but it can't be translated directly to an expression tree. This Project will generate an error by default and suggest 2 solutions: Either you rewrite the function to excplitly check for nullables or you let the generator do that for you!
This is a perfectly valid arrow function but it can't be translated directly to an expression tree. This Project will generate an error by default and suggest 2 solutions: Either you rewrite the function to explicitly check for nullables or you let the generator do that for you!
Starting from the official release of V2, we can now hint the generator in how to translate this arrow function to an expression tree. We can say:
```csharp
@@ -127,12 +127,12 @@ This is perfect for a database like SQL Server where nullability is implicit and
```
This will rewrite your expression to explicitly check for nullables. In the former example, this will be rewritten to:
```csharp
(user != null ? user.Location != nulll ? user.Location?.AddressLine 1 + (user != null ? user.Location != null ? user.Location.AddressLine2 : null) : null)
(user != null ? user.Location != null ? user.Location?.AddressLine 1 + (user != null ? user.Location != null ? user.Location.AddressLine2 : null) : null)
```
Note that using rewrite (not ignore) may increase the actual SQL query complexity being generated with some database providers such as SQL Server
#### How does this relate to [Expressionify](https://github.com/ClaveConsulting/Expressionify)?
Expressionify is a project that was launched before this project. It has some overlapping features and uses similar approaches. When I first published this project, I was not aware of its existance so shame on me. Currently Expressionify targets a more focusses scope of what this project is doing and thereby it seems to be more limiting in its capabilities. Check them out though!
Expressionify is a project that was launched before this project. It has some overlapping features and uses similar approaches. When I first published this project, I was not aware of its existence so shame on me. Currently Expressionify targets a more focusses scope of what this project is doing and thereby it seems to be more limiting in its capabilities. Check them out though!
#### How does this relate to LinqKit/LinqExpander/...?
There are a few projects like [LinqKit](https://github.com/scottksmith95/LINQKit) that were created before we had code generators in dotnet. These are great options if you're stuck with classical EF or don't want to rely on code generation. Otherwise I would suggest that EntityFrameworkCore.Projectables and Expresssionify are superior approaches as they are able to rely on SourceGenerators to do most of the hard work.