Buildenator
Buildenator copied to clipboard
Generating subentites builders
The golden sample
the source generator should have possibility to generate as follows: Source:
public class Aggregate
{
public Entity Entity { get; set; }
}
public class Entity
{
/* */
}
[MakeBuilder(typeof(Aggregate), <NewOption?>)]
[<NewAttribute?>]
public partial class AggregateBuilder
{
}
Output:
public partial class AggregateBuilder
{
/* */
}
public partial class EntityBuilder
{
/* */
}
Detecting entities to generate builders
Namespace rule
To prevent generating wrongly builders for build-in types, or types from external libraries, the buildenator will detect subentities by the same root namespace of the parent entity.
e.x. this is correct:
NameSpaceRoot.Aggregate
NameSpaceRoot.SubNamespace.Entity
this is not correct:
NameSpaceRoot.Aggregate
SubNamespace.Entity
Filtering out value types
By default if the subentity has only one not sophisticated property/contr. parameter, it will be treated as a value type, so no additional builders will be created.
Configurability
- GenereteSubentitiesBuilders[True/False]: whether generating subentities builders [False by default]
- Should have possibility to set up a global config
Known problems and challenges
- How to easilly detect whether the entity is simple or not?
- Secondly, what about reference loop, i.e. one entity having the second one and vice versa?
- It should be one directional, and it means it'd require to remember what are parent entities and pass them to children.
- A user should have a possibility to override the subentities builder in a partial class. Probably it'd require an additional marker
For the future
- A thing to improve in the next iterations - loosen namespace rules, i.e. detect by the number of identifiers taken into the account. For example, if the AR has its namespace A.B.C.D, and we set up the number of identifiers to 2, then the generator will generate builders for each entity that has its namespace in the A.B scope.
To start simple - an entity is simple when has only one property/field. It's a false assumption, because this one property may be of a type that is sophisticated itself, but it'll be easy to implement and should cover most of the cases.