Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Builder Patterns for more flexible dataprep #39

Open
farlee2121 opened this issue Apr 7, 2019 · 3 comments
Open

Builder Patterns for more flexible dataprep #39

farlee2121 opened this issue Apr 7, 2019 · 3 comments
Labels
enhancement New feature or request question Further information is requested

Comments

@farlee2121
Copy link
Owner

A builder could enable complex data creation while keeping each custom dimension more independent (fewer parameter in each signature, mix and match scenarios).

Bogus already works as a builder, but is very generic and requires relatively verbose configuration (*.RuleFor( prop => prop.Rulestuff...))

Key concerns.

  • I want to keep my ability to create named scenarios
  • keep overall specification short
  • Keep ability for instance configuration (like persists to DB or not)
    • no static extentions
  • keep my orchestration layer that allows joint configuration and one handle to data preps
    • This means no creating an instance for every case (like with bogus)

Possible solutions

  • use a builder behind a normal dataprep (add complexity and extra definition, but fits all requirements)
  • Treat my builder like it's immutable or like a c# 8 record (which has the .With() method to create modified instances)
    • This could possibly chew memory
@farlee2121
Copy link
Owner Author

How to handle random vs. customized values? Unlike in the method-based data-prep, I can't count on knowing all customized properties up front.

  1. I could use bogus to generate an object up front, then have the builder overwrite properties
  • I can't tell what properties are custom and which are not, which may be weird in cases like reference ids.
  1. Fill unset properties before generating
  • requires extra effort, but clarifies existing values
  • simplifies cases where we start with a provided object
  1. Modify generation rules instead of modifying an object
  • more complex, but clearer usage for generating many objects
  • can easily lean on bogus default type rules

If I pursue choice 2, here are ways to fill values
https://stackoverflow.com/questions/26156577/is-there-a-jquery-extend-in-c
https://github.com/omuleanu/ValueInjecter
null sub in automapper: http://docs.automapper.org/en/stable/Null-substitution.html
conditional mapping http://docs.automapper.org/en/stable/Conditional-mapping.html
Q: can I handle all properties in one go? using a condition for == default(T)?

@farlee2121
Copy link
Owner Author

I'm realizing that bogus does most of the things I'm concluding i should do with my builder

  • update rules and defer generation until last moment
  • populate existing items from rule set
  • generate one or many based on same rules

It even allows named rule sets, but they are based on string keys : /. Too magical

What it doesn't provide well are terse customization and named scenarios per type. It also doesn't play well with having persistence or other configuration injected.
This leaves me with

  1. Stick mostly to current 1-call preps that wrap bogus scenarios (still argument heavy)
  2. Inherit from bogus and modify my dataprep to pump out configured instances with getters
    • this could get a little weird. What would I be injecting into other preps? an instance doesn't work, it needs to be a fresh instance on every call. I could use ninject/DI to automate something like that.
  3. Inherit from bogus and have a 'factory' class that just delivers configured instances

@farlee2121 farlee2121 added enhancement New feature or request question Further information is requested labels Apr 15, 2019
@farlee2121
Copy link
Owner Author

Here is a possible example in Bogus https://github.com/bchavez/Bogus/blob/master/Source/Bogus/Faker%5BT%5D.cs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request question Further information is requested
Projects
None yet
Development

No branches or pull requests

1 participant