Feedback: Csla 6 fluent configuration; are you finding it difficult to navigate?

[TheCakeMonster]

Feeback Sought

I've been finding the Csla 6 fluent configuration a little difficult to navigate when I need to - which doesn't seem good, as I've been involved in a couple of the discussions around its structure!

How are other people finding it?

I think there are a few small tweaks that might be worth considering. Nothing major, but some of the changes that would be breaking changes once we go live, so I'm keen to gather feedback and thoughts. Can you find the options you need? Are you happy with the syntax of the resulting expression in what you have created thus far?

I'm going to create specific discussions and issues about the specifics of some of my ideas, as I think the discussions are often easier if things are quite granular. However, this discussion thread exists if people have general comments. At the same time, it also serves to document for myself a couple of things I have learned about the details of implementing this fluent style of configuration over the past few weeks.

Learnings (No Feedback Required)

Some of these learnings are to do with the internals of the code, so they aren't all about the usage - but people may find them useful in the future if you build configuration in libraries of their own.

Firstly, it has dawned on me that it's important to approach configuration as a logical two step process that needs to be reflected in the internals of the code. These two have to be separated so that they happen in the right order:

1. Define
2. Apply

Some of our extension methods have previously done the apply step as soon as you call the method; one or two may still do so at the time of writing. This can lead to subtle bugs depending on the order in which the methods are called, or whether they get called more than once.

Secondly, the Builder pattern - where you create an instance of a builder type, call methods on it, and then call Build to get the thing you need, might be better for very complex configuration, because you can more easily separate out the configuration into different, simpler, lines of code. If a lambda expression gets too big then it becomes hard to reason about. For example, finding typos in brackets and so on can become more difficult. I don't think Csla is at the point where this is necessary, but other people might disagree.

The Builder pattern also helps with the separation of the define and apply steps mentioned above, so it helps further reduce the possibility for bugs.

I think we can add a configuration builder for Csla's configuration at a later date without a breaking change, so I'm not concerned with doing this now - if ever.

Thirdly, there is a bit of a trade-off between fluency and ease of use without Builder. If you create a method that returns an options object with a subset of the total available options then it often leads to more fluent statements, but you are a bit more limited in what you can do for the remainder of the statement. For example, the DataPortal() method exists to expose a subset of config, but because of that, you can't method chain a config for Security() directly after DataPortal(), as there is (currently, anyway) no way to go back up to the main options again. I think Builder might be able to achieve a better mix of these qualities.

Like I say, I'm not advocating for Builder - even though it might appear I am as I reread the previous paragraphs. I am just documenting all of my somewhat unstructured thoughts at this point, in case they are useful to those that come after us - including me should I need to revisit this in the future!

Detailed discussions on individual changes can be found under the following topics

Potential breaking changes
#2691
#2694
#2701

Non-breaking suggestions
#2692
#2699

[swegele]

Yes, I also found it a bit clunky (not impossible), but I had to "fiddle with it" to get it right.
By "fiddle", I mean I had to consult one or two of the different demos in Csla project, and intellisense, and just playing with it till it worked. I will add comments to your other ticket that is more specific to DataPortal options.