Hi all, author here.

At its core Facet is not a mapper library but a source generator for facetted models.

This project was initially created as an answer to a reddit question (someone was looking for a library to source generate redacted models of existing models) and it evolved into a library that also provides the mapping. It is/was not meant to be the next best mapper. Thanks for the review and demo, already received a lot of feedback because of the spotlight here. I will improve and get to work soon!

- Tim

I prefer manual mapping using extension methods. Reasons: 1) Properties show as being used 2) Refactoring a property name updates the mapping 3) Changing a property type used by a mapping results in a compile time error 4) You can drill into the code; no black box 5) Absolute control over how the data is mapped 6) One less 3rd party library to go paid or break stuff when upgrading NET.

Lol, the DTO is autogenerated based on the mapped from type? That's completely backwards.
DTOs typically are part of your API contracts and should be manually defined and should never change automatically as that would break your API contracts.

I'm still on the "just map it yourself" train but this library is surely interesting. It brings a little bit of a feeling of "structural typing" (although it's definitely not). Will check it out!

I did a double take on the thumbnail when I misread "better than napping" because right now there's no such thing.

What's different about it compared to the Mapperly library?

5:41 I noticed that the Projection expression is just '(source) => new PersonDto(source)', this could be an issue performance-wise, since the constructor call does not contain information on what properties are required, so EF cannot analyze what columns are needed, and which can be omitted.
So it will most likely load the full Person object and all it's data, which could be very wasteful if you're loading a lot of data and throw away a bunch of columns (e.g. Id, DateCreated, DateModified, etc.).

I might be completely wrong on this, but it is worth mentioning, I think.

About what you asked at about 3:11. The fact that you have to provide both types in the generic class comes from the fact, that this is an extension method. If it would be a member method, you could write it with just one generic parameter, but the extension method needs both.

In .net  you either can set both generic parameters explicitly or leave them both if they can be derived automatically. Unfortunately it is not possible to just provide one argument and let the other argument be implicit (like it is in other languages like C++).

So one way to circumvent this, would be an out parameter instead of a return, than you could write "person.ToFacet(out PersonDto dto)" (out something like that). Because then both types are implicit.

(Note: That is just an example, I don't know if Facet actually has this overload. but you could create this overload yourself with an extension method.)

I just prefer doing my projection mapping manually into static mapping extension classes.

But it's still cool because now I know the way I do projection is actually the proper way to use EF Core.

Lately, with so many open-source packages becoming paid, I've really embraced a DIY approach, especially for things like manual mapping. I use DTOs with required and init properties like public required string OrderId { get; init; } and use AI to generate the mapping code. This gives you full control and avoids potential licensing issues if a package ever becomes a paid product.

B-but isn't the idea of DTOs to have them defined explicitly in the code, so they change completely independently of other types and map to/from them?

For me the best mapping lib is mapperly

There is one interesting feature of OG AutoMapper I actually like, which is in fact one of the few reasons to use it. It can transform any IExpression on one type into IExpression on the other type, which effectively allows you to write LINQ query on DTO and EF will translate it to proper SQL. Quite useful e.g. when implementing OData endpoint

I'm completely against auto mapping strategies as they hide complexities that should not be hidden. If you just need to "cast" from one object to another,  manually specifying properties are easy enough, and is explicit enough to let everyone know that this is just it, a simple conversion of data representation, no magic properties discoveries and reflection should be needed. On the other cases where you must transform data to fit the DTO should be treated with caution as it can be an indicator of a behavior that should be explicit and well know by the team and maybe by the consumer of your API's. You shouldn't just "try to fit" information from one representation to another. What if your DTO requires some information that is not yet present on the current entity and must be fetched from the database? What does this means for your domain model? You cant just slap auto mapper there and hope for the best...

On one hand I see some of the benefits. On the other hand there is still a lot of auto-magical behavior and hidden coupling that could make testing scenarios more complicated. We're replacing a hand-built mapper class with a hand-built "configurator" class and an attribute that has to point to it, and then extension methods that can't use type-inference so they are more verbose than necessary? The DB projection stuff and LINQ integration stuff is nice, but I still don't think this library is going to change my opinion against using mapping libraries.

3:10 You need to provide both generic arguments because it's an extension method. Since extension methods are just static methods inside non-generic static classes, you can't get around the necessity of passing all generic arguments

Love it. Thanks for exposing me to Rider also ❤

My guess on needing to know the TSource might be a problem I ran into with c#. I was trying to create an expression where I wanted to use a Known type as a Generic.

Ex. If I have an Expression<Func<TSource, TDest>> where you know the TSource. In C# doesn't support self reference Generics, say <typeof(this)>. I'm assuming they are trying to self reference the source for intelligence and lambdas. It has been talked about before.

There is some voodoo extension method magic that can be done with double dispatching extensions methods. It's a cluster tho.

I can see why this can be very convenient. If you have ever seen how simple object mapping is Kotlin with the built-in extension function support... it is *chef's kiss. You can literally call it by for eg. val personDto = person.toPersonDto() or whatever you decide to name your extension function. If the types can be inferred instead of having to be passed in <> it would be perfect.

What's the difference between this and mapperly?