Name | Operating System | Status | History |
---|---|---|---|
GitHub Actions | Ubuntu, Mac & Windows |
If you like or are using this project please give it a star. Thanks!
Vogen is a .NET Source Generator and analyzer. It turns your primitives (ints, decimals etc.) into value objects that represent domain concepts (CustomerId, AccountBalance etc.)
It adds new C# compilation errors to help stop the creation of invalid value objects.
The source generator generates strongly typed domain concepts. You provide this:
[ValueObject<int>]
public partial struct CustomerId {
}
... and Vogen generates source similar to this:
public partial struct CustomerId : System.IEquatable<CustomerId>, System.IComparable<CustomerId>, System.IComparable {
private readonly int _value;
public readonly int Value => _value;
public CustomerId() {
throw new Vogen.ValueObjectValidationException("Validation skipped by attempting to use the default constructor...");
}
private CustomerId(int value) => _value = value;
public static CustomerId From(int value) {
CustomerId instance = new CustomerId(value);
return instance;
}
public readonly bool Equals(CustomerId other) ...
public readonly bool Equals(int primitive) ...
public readonly override bool Equals(object obj) ...
public static bool operator ==(CustomerId left, CustomerId right) ...
public static bool operator !=(CustomerId left, CustomerId right) ...
public static bool operator ==(CustomerId left, int right) ...
public static bool operator !=(CustomerId left, int right) ...
public static bool operator ==(int left, CustomerId right) ...
public static bool operator !=(int left, CustomerId right) ...
public readonly override int GetHashCode() ...
public readonly override string ToString() ...
}
You then use CustomerId
instead of int
in your domain in the full knowledge that it is valid and safe to use:
CustomerId customerId = CustomerId.From(123);
SendInvoice(customerId);
...
public void SendInvoice(CustomerId customerId) { ... }
Note:
int
is the default type for value objects, but it is generally a good idea to explicitly declare each type for clarity. Plus, althoughint
is the default, you can - individually or globally - configure them to be other types. See the Configuration section later in the document, but here's some brief examples:
[ValueObject<decimal>]
public partial struct AccountBalance { }
[ValueObject(typeof(string))]
public partial class LegalEntityName { }
The main goal of Vogen is to ensure the validity of your value objects, the code analyser helps you to avoid mistakes which might leave you with uninitialized value objects in your domain.
It does this by adding new constraints in the form of new C# compilation errors. There are a few ways you could end up with uninitialized value objects. One way is by giving your type constructors. Providing your own constructors could mean that you forget to set a value, so Vogen doesn't allow you to have user defined constructors:
[ValueObject]
public partial struct CustomerId {
// Vogen deliberately generates this so that you can't create your own:
// error CS0111: Type 'CustomerId' already defines a member called 'CustomerId' with the same parameter type
public CustomerId() { }
// error VOG008: Cannot have user defined constructors, please use the From method for creation.
public CustomerId(int value) { }
}
In addition, Vogen will spot issues when creating or consuming value objects:
// catches object creation expressions
var c = new CustomerId(); // error VOG010: Type 'CustomerId' cannot be constructed with 'new' as it is prohibited
CustomerId c = default; // error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
var c = default(CustomerId); // error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
var c = GetCustomerId(); // error VOG010: Type 'CustomerId' cannot be constructed with 'new' as it is prohibited
var c = Activator.CreateInstance<CustomerId>(); // error VOG025: Type 'CustomerId' cannot be constructed via Reflection as it is prohibited.
var c = Activator.CreateInstance(typeof(CustomerId)); // error VOG025: Type 'MyVo' cannot be constructed via Reflection as it is prohibited
// catches lambda expressions
Func<CustomerId> f = () => default; // error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
// catches method / local function return expressions
CustomerId GetCustomerId() => default; // error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
CustomerId GetCustomerId() => new CustomerId(); // error VOG010: Type 'CustomerId' cannot be constructed with 'new' as it is prohibited
CustomerId GetCustomerId() => new(); // error VOG010: Type 'CustomerId' cannot be constructed with 'new' as it is prohibited
// catches argument / parameter expressions
Task<CustomerId> t = Task.FromResult<CustomerId>(new()); // error VOG010: Type 'CustomerId' cannot be constructed with 'new' as it is prohibited
void Process(CustomerId customerId = default) { } // error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
One of the main goals of this project is to achieve almost the same speed and memory performance as using primitives directly.
Put another way, if your decimal
primitive represents an Account Balance, then there is extremely low overhead of
using an AccountBalance
value object instead. Please see the performance metrics below.
Vogen is a Nuget package. Install it with:
dotnet add package Vogen
When added to your project, the source generator generates the wrappers for your primitives and the code analyser will let you know if you try to create invalid value objects.
Think about your domain concepts and how you use primitives to represent them, e.g. instead of this:
public void HandlePayment(int customerId, int accountId, decimal paymentAmount)
... have this:
public void HandlePayment(CustomerId customerId, AccountId accountId, PaymentAmount paymentAmount)
It's as simple as creating types like this:
[ValueObject]
public partial struct CustomerId { }
[ValueObject]
public partial struct AccountId { }
[ValueObject<decimal>]
public partial struct PaymentAmount { }
The source generator generates value objects. value objects help combat Primitive Obsession by wrapping simple primitives such as int
, string
, double
etc. in a strongly-typed type.
Primitive Obsession (AKA StringlyTyped) means being obsessed with primitives. It is a Code Smell that degrades the quality of software.
"Primitive Obsession is using primitive data types to represent domain ideas" #
Some examples:
- instead of
int age
- we'd haveAge age
.Age
might have validation that it couldn't be negative - instead of
string postcode
- we'd havePostcode postcode
.Postcode
might have validation on the format of the text
The source generator is opinionated. The opinions help ensure consistency. The opinions are:
- A value object (VO) is constructed via a factory method named
From
, e.g.Age.From(12)
- A VO is equatable (
Age.From(12) == Age.From(12)
) - A VO, if validated, is validated with a static method named
Validate
that returns aValidation
result - Any validation that is not
Validation.Ok
results in aValueObjectValidationException
being thrown
It is common to represent domain ideas as primitives, but primitives might not be able to fully describe the domain idea.
To use value objects instead of primitives, we simply swap code like this:
public class CustomerInfo {
private int _id;
public CustomerInfo(int id) => _id = id;
}
.. to this:
public class CustomerInfo {
private CustomerId _id;
public CustomerInfo(CustomerId id) => _id = id;
}
There's a blog post here that describes it, but to summarise:
Primitive Obsession is being obsessed with the seemingly convenient way that primitives, such as
ints
andstrings
, allow us to represent domain objects and ideas.
It is this:
int customerId = 42
What's wrong with that?
A customer ID likely cannot be fully represented by an int
. An int
can be negative or zero, but it's unlikely a customer ID can be. So, we have constraints on a customer ID. We can't represent or enforce those constraints on an int
.
So, we need some validation to ensure the constraints of a customer ID are met. Because it's in int
, we can't be sure if it's been checked beforehand, so we need to check it every time we use it. Because it's a primitive, someone might've changed the value, so even if we're 100% sure we've checked it before, it still might need checking again.
So far, we've used as an example, a customer ID of value 42
. In C#, it may come as no surprise that "42 == 42
" (I haven't checked that in JavaScript!). But, in our domain, should 42
always equal 42
? Probably not if you're comparing a Supplier ID of 42
to a Customer ID of 42
! But primitives won't help you here (remember, 42 == 42
!).
(42 == 42) // true
(SuppliedId.From(42) == SupplierId.From(42)) // true
(SuppliedId.From(42) == VendorId.From(42)) // compilation error
But sometimes, we need to denote that a value object isn't valid or has not been set. We don't want anyone outside of the object doing this as it could be used accidentally. It's common to have Unspecified
instances, e.g.
public class Person {
public Age Age { get; } = Age.Unspecified;
}
We can do that with an Instance
attribute:
[ValueObject]
[Instance("Unspecified", -1)]
public readonly partial struct Age {
public static Validation Validate(int value) =>
value > 0 ? Validation.Ok : Validation.Invalid("Must be greater than zero.");
}
This generates public static Age Unspecified = new Age(-1);
. The constructor is private
, so only this type can (deliberately) create invalid instances.
Now, when we use Age
, our validation becomes clearer:
public void Process(Person person) {
if(person.Age == Age.Unspecified) {
// age not specified.
}
}
We can also specify other instance properties:
[ValueObject(typeof(float))]
[Instance("Freezing", 0)]
[Instance("Boiling", 100)]
public readonly partial struct Celsius {
public static Validation Validate(float value) =>
value >= -273 ? Validation.Ok : Validation.Invalid("Cannot be colder than absolute zero");
}
Each value object can have it's own optional configuration. Configuration includes:
- The underlying type
- Any 'conversions' (Dapper, System.Text.Json, Newtonsoft.Json, etc.) - see the Integrations page in the wiki for more information
- The type of the exception that is thrown when validation fails
If any of those above are not specified, then global configuration is inferred. It looks like this:
[assembly: VogenDefaults(underlyingType: typeof(int), conversions: Conversions.Default, throws: typeof(ValueObjectValidationException))]
Those again are optional. If they're not specified, then they are defaulted to:
- Underlying type =
typeof(int)
- Conversions =
Conversions.Default
(TypeConverter
andSystem.Text.Json
) - Validation exception type =
typeof(ValueObjectValidationException)
There are several code analysis warnings for invalid configuration, including:
- when you specify an exception that does not derive from
System.Exception
- when your exception does not have 1 public constructor that takes an int
- when the combination of conversions does not match an entry
(to run these yourself: dotnet run -c Release --framework net8.0 -- --job short --filter *
in the Vogen.Benchmarks
folder)
As mentioned previously, the goal of Vogen is to achieve very similar performance compare to using primitives themselves. Here's a benchmark comparing the use of a validated value object with underlying type of int vs using an int natively (primitively ๐ค)
BenchmarkDotNet=v0.13.2, OS=Windows 11 (10.0.22621.1194)
AMD Ryzen 9 5950X, 1 CPU, 32 logical and 16 physical cores
.NET SDK=7.0.102
[Host] : .NET 7.0.2 (7.0.222.60605), X64 RyuJIT AVX2
ShortRun : .NET 7.0.2 (7.0.222.60605), X64 RyuJIT AVX2
Job=ShortRun IterationCount=3 LaunchCount=1
WarmupCount=3
Method | Mean | Error | StdDev | Ratio | RatioSD | Gen0 | Allocated |
---|---|---|---|---|---|---|---|
UsingIntNatively | 14.55 ns | 1.443 ns | 0.079 ns | 1.00 | 0.00 | - | - |
UsingValueObjectStruct | 14.88 ns | 3.639 ns | 0.199 ns | 1.02 | 0.02 | - | - |
There is no discernible difference between using a native int and a VO struct; both are pretty much the same in terms of speed and memory.
The next most common scenario is using a VO class to represent a native String
. These results are:
BenchmarkDotNet=v0.13.2, OS=Windows 11 (10.0.22621.1194)
AMD Ryzen 9 5950X, 1 CPU, 32 logical and 16 physical cores
.NET SDK=7.0.102
[Host] : .NET 7.0.2 (7.0.222.60605), X64 RyuJIT AVX2
ShortRun : .NET 7.0.2 (7.0.222.60605), X64 RyuJIT AVX2
Job=ShortRun IterationCount=3 LaunchCount=1
WarmupCount=3
Method | Mean | Error | StdDev | Ratio | RatioSD | Gen0 | Allocated | Alloc Ratio |
---|---|---|---|---|---|---|---|---|
UsingStringNatively | 151.8 ns | 32.19 | 1.76 | 1.00 | 0.00 | 0.0153 | 256 B | 1.00 |
UsingValueObjectAsStruct | 184.8 ns | 12.19 | 0.67 | 1.22 | 0.02 | 0.0153 | 256 B | 1.00 |
There is a tiny amount of performance overhead, but these measurements are incredibly small. There is no memory overhead.
By default, each VO is decorated with a TypeConverter
and System.Text.Json
(STJ) serializer. There are other converters/serializer for:
- Newtonsoft.Json (NSJ)
- Dapper
- EFCore
- LINQ to DB
- protobuf-net (see the FAQ section below)
They are controlled by the Conversions
enum. The following has serializers for NSJ and STJ:
[ValueObject(conversions: Conversions.NewtonsoftJson | Conversions.SystemTextJson, underlyingType: typeof(float))]
public readonly partial struct Celsius { }
If you don't want any conversions, then specify Conversions.None
.
If you want your own conversion, then again specify none, and implement them yourself, just like any other type. But be aware that even serializers will get the same compilation errors for new
and default
when trying to create VOs.
If you want to use Dapper, remember to register it - something like this:
SqlMapper.AddTypeHandler(new Customer.DapperTypeHandler());
See the examples folder for more information.
Yes, it's here: https://stevedunn.github.io/Vogen/vogen.html
The source generator is .NET Standard 2.0. The code it generates supports all C# language versions from 6.0 and onwards
If you're using the generator in a .NET Framework project and using the old style projects (the one before the 'SDK style' projects), then you'll need to do a few things differently:
- add the reference using
PackageReference
in the .csproj file:
<ItemGroup>
<PackageReference Include="Vogen" Version="[LATEST_VERSION_HERE - E.G. 1.0.18]" PrivateAssets="all" />
</ItemGroup>
- set the language version to
latest
(or anything8
or more):
<PropertyGroup>
+ <LangVersion>latest</LangVersion>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
This is primarily a source generator. The source it generates is mostly C# 6 for compatibility. But if you use features from a later language version, for instance records
from C# 9, then it will also generate records.
Source generation is driven by attributes, and, if you're using .NET 7 or above, the generic version of the ValueObject
attribute is exposed:
[ValueObject<int>]
public partial struct Age { }
The term value object represents a small object who's equality is based on value and not identity. From Wikipedia
In computer science, a value object is a small object that represents a simple entity whose equality is not based on identity: i.e. two value objects are equal when they have the same value, not necessarily being the same object.
In DDD, a value object is (again, from Wikipedia)
... a value object is an immutable object that contains attributes but has no conceptual identity
Add this to your .csproj
file:
<PropertyGroup>
<EmitCompilerGeneratedFiles>true</EmitCompilerGeneratedFiles>
<CompilerGeneratedFilesOutputPath>Generated</CompilerGeneratedFilesOutputPath>
</PropertyGroup>
<ItemGroup>
<Compile Remove="Generated/*/**/*.cs" />
</ItemGroup>
Then, you can view the generated files in the Generated
folder. In Visual Studio, you need to select 'Show all files' in the Solution Explorer window:
Here's an example from the included Samples
project:
That doesn't give you validation. To validate Value
, you can't use the shorthand syntax (Primary Constructor). So you'd need to do:
public record struct CustomerId
{
public CustomerId(int value) {
if(value <=0) throw new Exception(...)
}
}
You might also provide other constructors which might not validate the data, thereby allowing invalid data into your domain. Those other constructors might not throw exception, or might throw different exceptions. One of the opinions in Vogen is that any invalid data given to a value object throws a ValueObjectValidationException
.
You could also use default(CustomerId)
to evade validation. In Vogen, there are analysers that catch this and fail the build, e.g:
// error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
CustomerId c = default;
// error VOG009: Type 'CustomerId' cannot be constructed with default as it is prohibited.
var c2 = default(CustomerId);
Yes. By default, each VO is decorated with a TypeConverter
and System.Text.Json
(STJ) serializer. There are other converters/serializers for:
- Newtonsoft.Json (NSJ)
- Dapper
- EFCore
- LINQ to DB
Yes, although there are certain considerations. Please see the EFCore page on the Wiki, but the TL;DR is:
- You need a conversion to be generated, e.g.
[ValueObject<string>(conversions: Conversions.EfCoreValueConverter)]
and you need to tell EFCore to use that converter in theOnModelCreating
method, e.g.:
builder.Entity<SomeEntity>(b =>
{
b.Property(e => e.Name).HasConversion(new Name.EfCoreValueConverter());
});
You could, but to ensure consistency throughout your domain, you'd have to validate everywhere. And Shallow's Law says that that's not possible:
โ๏ธ Shalloway's Law "when N things need to change and N > 1, Shalloway will find at most N - 1 of these things."
Concretely: "When 5 things need to change, Shalloway will find at most, 4 of these things."
Yes. The analyzer generates a compilation error.
Yes. The analyzer generates a compilation error.
No. The parameter-less constructor is generated automatically, and the constructor that takes the underlying value is also generated automatically.
If you add further constructors, then you will get a compilation error from the code generator, e.g.
[ValueObject(typeof(int))]
public partial struct CustomerId {
// Vogen already generates this as a private constructor:
// error CS0111: Type 'CustomerId' already defines a member called 'CustomerId' with the same parameter type
public CustomerId() { }
// error VOG008: Cannot have user defined constructors, please use the From method for creation.
public CustomerId(int value) { }
}
You could, but you'd get compiler warning CS0282-There is no defined ordering between fields in multiple declarations of partial class or struct 'type'
Why are there, by default, no implicit conversions to and from the primitive types that are being wrapped?
Implicit operators can be useful, but for value objects, they can confuse things. Take the following code without any implicit conversions:
Age age1 = Age.From(1);
OsVersion osVersion = OsVersion.From(1);
Console.WriteLine(age1 == osVersion); // won't compile! \o/
That makes perfect sense. But adding in an implicit operator from Age
to int
, and it does compile!
Console.WriteLine(age1 == osVersion); // TRUE! (โ_โ;)
If we remove that implicit operator and replace it with an implicit operator from int
to Age
, it no longer compiles, which is great (we've got type safety back), but we end up violating the rules of implicit operators:
Predefined C# implicit conversions always succeed and never throw an exception. User-defined implicit conversions should behave in that way as well. If a custom conversion can throw an exception or lose information, define it as an explicit conversion
In my research, I read some other opinions, and noted that the guidelines listed in this answer say:
- If the conversion can throw an
InvalidCast
exception, then it shouldn't be implicit. - If the conversion causes a heap allocation each time it is performed, then it shouldn't be implicit.
Which is interesting - Vogen wouldn't throw an InvalidCastException
(only an ValueObjectValidationException
). Also, for struct
s, we wouldn't create a heap allocation.
But since users of Vogen can declare a value object as a class
or struct
, then we wouldn't want implicit operators (from primitive
=> ValueObject
) for just structs
and not class
es.
Yes, by specifying the toPrimitiveCasting
and fromPrimitiveCasting
in either local or global config.
By default, explicit operators are generated for both. Bear in mind that you can only define implicit or explicit operators;
you can't have both.
Also, bear in mind that ease of use can cause confusions. Let's say there's a type like this (and imagine that there's implicit conversions to Age
and to int
'):
[ValueObject(typeof(int))]
public readonly partial struct Age {
public static Validation Validate(int n) => n >= 0 ? Validation.Ok : Validation.Invalid("Must be zero or more");
}
That says that Age
instances can never be negative. So you would probably expect the following to throw, but it doesn't:
var age20 = Age.From(20);
var age10 = age20 / 2;
++age10;
age10 -= 12; // bang - goes negative??
The implicit cast in var age10 = age20 / 2
results in an int
and not an Age
. Changing it to Age age10 = age20 / 2
fixes it. But this does go to show that it can be confusing.
If I'm using a library that uses Vogen, I'd like to easily tell if the type is just a primitive wrapper or not by the fact that it implements an interface, such as
IValidated<T>
Just like primitives have no interfaces, there's no need to have interfaces on value objects. The receiver that takes a CustomerId
knows that it's a value object. If it were instead to take an IValidated<int>
, then it wouldn't have any more information; you'd still have to know to call Value
to get the value.
It might also relax type safety. Without the interface, we have signatures such as this:
public void SomSomething(CustomerId customerId, SupplierId supplierId, ProductId productId);
... but with the interface, we could have signatures such as this:
public void SomSomething(IValidate<int> customerId, IValidated<int> supplierId, IValidated<int> productId);
So, callers could mess things up by calling DoSomething(productId, supplierId, customerId)
)
There would also be no need to know if it's validated, as, if it's in your domain, it's valid (there's no way to manually create invalid instances). And with that said, there would also be no point in exposing the 'Validate' method via the interface because validation is done at creation.
Yes. You might want to represent special values for things like invalid or unspecified instances, e.g.
/*
* Instances are the only way to avoid validation, so we can create instances
* that nobody else can. This is useful for creating special instances
* that represent concepts such as 'invalid' and 'unspecified'.
*/
[ValueObject]
[Instance("Unspecified", -1)]
[Instance("Invalid", -2)]
public readonly partial struct Age
{
private static Validation Validate(int value) =>
value > 0 ? Validation.Ok : Validation.Invalid("Must be greater than zero.");
}
You can then use default values when using these types, e.g.
public class Person {
public Age Age { get; set; } = Age.Unspecified
}
... and if you take an Age, you can compare it to an instance that is invalid/unspecified
public void CanEnter(Age age) {
if(age == Age.Unspecified || age == Age.Invalid) throw CannotEnterException("Age not specified or is invalid")
return age < 17;
}
I'd like normalize/sanitize the values used, for example, trimming the input. Is this possible?
Yes, add NormalizeInput method, e.g.
private static string NormalizeInput(string input) => input.Trim();
See wiki for more information.
Yes, but (at the moment) it requires that you put your defaults in your attribute's constructor - not in the call to the base class' constructor (see this comment).
public class CustomValueObjectAttribute : ValueObjectAttribute<long>
{
// This attribute will default to having both the default conversions and EF Core type conversions
public CustomValueObjectAttribute(Conversions conversions = Conversions.Default | Conversions.EfCoreValueConverter) { }
}
NOTE: custom attributes must extend a ValueObjectAttribute class; you cannot layer custom attributes on top of each other
It would be great if it was, but it's not currently. I wrote an article about it, but in summary, there is a long-standing language proposal focusing on non-defaultable value types. Having non-defaultable value types is a great first step, but it would also be handy to have something in the language to enforce validate. So I added a language proposal for invariant records.
One of the responses in the proposal says that the language team decided that validation policies should not be part of C#, but provided by source generators.
StronglyTypedId This is focused more on IDs. Vogen is focused more of 'Domain Concepts' and the constraints associated with those concepts.
StringlyTyped This is my first attempt and is NON source-generated. There is memory overhead because the base type is a class. There are also no analyzers. It is now marked as deprecated in favor of Vogen.
ValueOf Similar to StringlyTyped - non source-generated and no analysers. This is also more relaxed and allows composite 'underlying' types.
ValueObjectGenerator Similar to Vogen, but less focused on validation and no code analyzer.
Any type can be wrapped. Serialisation and type conversions have implementations for:
-
string
-
int
-
long
-
short
-
byte
-
float (Single)
-
decimal
-
double
-
DateTime
-
DateOnly
-
TimeOnly
-
DateTimeOffset
-
Guid
-
bool
For other types, a generic type conversion and serializer is applied. If you are supplying your own converters for type conversion and serialization, then specify None
for converters and decorate your type with attributes for your own types, e.g.
[ValueObject(typeof(SpecialPrimitive), conversions: Conversions.None)]
[System.Text.Json.Serialization.JsonConverter(typeof(SpecialPrimitiveJsonConverter))]
[System.ComponentModel.TypeConverter(typeof(SpecialPrimitiveTypeConverter))]
public partial struct SpecialMeasurement { }
Yes, by specifying the exception type in either the ValueObject
attribute, or globally, with VogenConfiguration
.
I get an error from Linq2DB when I use a ValueObject that wraps a TimeOnly
saying that DateTime
cannot be converted to TimeOnly
- what should I do?
Linq2DB 4.0 or greater supports DateOnly
and TimeOnly
. Vogen generates value converters for Linq2DB; for DateOnly
, it just works, but for `TimeOnly, you need to add this to your application:
MappingSchema.Default.SetConverter<DateTime, TimeOnly>(dt => TimeOnly.FromDateTime(dt));
Yes. Add a dependency to protobuf-net and set a surrogate attribute:
[ValueObject(typeof(string))]
[ProtoContract(Surrogate = typeof(string))]
public partial class BoxId {
//...
}
BoxId type now will be serialized as a string in all messages/grpc calls. If one is generating .proto files for other applications from C# code, proto files will include Surrogate type as the type. thank you to @DomasM for this information.
I took a lot of inspiration from Andrew Lock's StronglyTypedId.
I also got some great ideas from Gรฉrald Barrรฉ's Meziantou.Analyzer