Open devbased opened 2 years ago
Is that necessarily a problem with generated code? Does it reference your Infrastructure
layer or merely references dapper/ef assemblies?
I can understand the problem if it was hand-crafted code, as it'd break the inward-dependency rule.
Hi @SteveDunn - I'm not sure I follow your rationale here. Isn't the fact that a domain object has a direct dependency on some "infrastructure", e.g. EF Core, the very essence of "breaking the inward-dependency rule"? I don't understand how it matters if it's mine or somebody else's code that I depend, or if it's auto-generated. Can you elaborate on your thinking please?
Hi @prlcutting - the way I see it is, the attribute acts as an abstraction over infrastructure concerns. Your domain ideas (types) are still domain specific, and have no intimate knowledge of infrastructure, but rather, just general knowledge of various persistence mechanisms.
Personally though, I tend to only use primitives in the DTOS that are [de]serialized outside of my application boundary.
I see the logic in @devbased 's request.
Suppose I have the following project structure
MyApp.Core
(Class Library)
StronglyTypedId
MyApp.Web
(Web API project)
MyApp.Standalone
(Desktop / Console app)
System.Text.Json
And I have an ID, FooId
in MyApp.Core
. Each of the consuming apps (MyApp.Web
and MyApp.Standalone
both have their own way of doing things. The web app pulls its data from a database. The standalone app pulls its data from JSON files.
With the current design, I have two options:
MyApp.Core
has to reference both my database library (EF/Dapper/etc.) and System.Text.Json
.
MyApp.Standalone
is not using any database stuff, it has to include those binaries.StronglyTypedId
library generate the serialization converters.
I think there would be value in a [StronglyTypedIdSerializer]
attribute. When applied to a partial
class, it looks at the base type of the converter, determines what kind of serializer to generate, and generates the appropriate one. This type need not be in the same assembly as the ID we're generating a type for (but obviously, that assembly must be referenced)
[StronglyTypedIdSerializer]
public partial class FooIdConverter : System.Text.Json.Serialization.JsonConverter<FooId>
{
}
Considering we have the ability to completely customize templates, if I could only add [StronglyTypedId] to a class, I could create templates for my converters manually and this would work as is. Unfortunately it can only be placed on structs, which makes sense for what it was intended for.
I'm not trying to poach users from this great tool, but Vogen now generates ERCore converters in a separate assembly. Vogen is aimed more at value objects than IDs, but it can represent IDs just fine.
I'm not trying to poach users from this great tool, but Vogen now generates ERCore converters in a separate assembly. Vogen is aimed more at value objects than IDs, but it can represent IDs just fine.
Thanks for the tip @SteveDunn, I was not aware of this library. Unfortunately in my case I want my JsonConverters in a separate assembly, which I can't seem to find a way to to with Vogen currently. (The reason is I have a library that needs to support json converters for both Newtonsoft and STJ in separate assemblies).
Ah, I see. Vogen can generate system.text.json converters and factories in a separate assembly, but it doesn't do newtonsoft.json
By specifying converters in attribute we automatically tie domain layer with infrastructure.