Eliminate hardcoded DataPortal_XYZ method names

[rockfordlhotka]

Today the DataPortal_XYZ and Child_XYZ method names are hardcoded into the data portal. They should not be hardcoded.

In short, people should be able to come up with their own naming convention for these methods, and the data portal should invoke the appropriate methods.

UPDATE: This comment has a detailed list of the options being considered.

[JasonBock]

I'm biased here, but I like it 👍 . Honestly, this should be the way it was done from Day 1, and I can see this same approach being used in other places in CSLA (rule registration is another, but let's just start with these for now).

One thing I'd like to see is what the difference is with method discovery via attributes vs a well-known name. The difference would probably be small and I believe CSLA caches the method once it's found, but it would be fun to Benchmark.NET that to see what it is.

[JasonBock]

I also think having an analyzer here would help people easily move to this attribute approach (assuming it's better all around). We could offer adding the attribute to operations automatically, and then at some point, the internals of CSLA remove that method lookup path, but the analyzer would stick around for a while to help developers easily update code.

[JasonBock]

Before we go too far down this road, I decided to do some perf testing. First, I defined a [FetchAttribute]:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = false)]
public sealed class FetchAttribute
  : Attribute
{ }

I created a bunch of classes that contained either methods decorated with a [FetchAttribute]:

[Fetch]
void Method1(Guid id) { }

or a well-known name:

void DataPortal_Fetch(int id) { }

I created classes with 5, 10, 20 and 50 methods. A class either contained 2 attributed methods, or 2 well-known named methods. The lookup code looked like this:

[Benchmark]
public int FindMethodCountWith5UsingIsDefined() =>
  typeof(ClassWith5MethodsAndAttribute)
    .GetMethods(BindingFlags.Instance | BindingFlags.NonPublic)
    .Where(_ => _.IsDefined(typeof(FetchAttribute))).Count();

[Benchmark]
public int FindMethodCountWith5UsingGetCustomAttribute() =>
  typeof(ClassWith5MethodsAndAttribute)
    .GetMethods(BindingFlags.Instance | BindingFlags.NonPublic)
    .Where(_ => _. GetCustomAttribute<FetchAttribute>() != null).Count();

[Benchmark]
public int FindMethodCountWith5UsingWellKnownName() =>
  typeof(ClassWith5MethodsAndWellKnownName)
    .GetMethods(BindingFlags.Instance | BindingFlags.NonPublic)
    .Where(_ => _.Name == FetchMethod).Count();

There are various ways to determine if a member has an attribute - the two I've included in my tests seem to be the best approaches. Here are the results:

BenchmarkDotNet=v0.11.4, OS=Windows 10.0.17763.316 (1809/October2018Update/Redstone5)
Intel Core i7-7820HQ CPU 2.90GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=2.2.105
  [Host]     : .NET Core 2.2.3 (CoreCLR 4.6.27414.05, CoreFX 4.6.27414.05), 64bit RyuJIT
  DefaultJob : .NET Core 2.2.3 (CoreCLR 4.6.27414.05, CoreFX 4.6.27414.05), 64bit RyuJIT

|                                       Method |        Mean |      Error |    StdDev | Gen 0/1k Op | Gen 1/1k Op | Gen 2/1k Op | Allocated Memory/Op |
|--------------------------------------------- |------------:|-----------:|----------:|------------:|------------:|------------:|--------------------:|
|           FindMethodCountWith5UsingIsDefined |  3,134.9 ns |  62.158 ns | 116.75 ns |      0.1335 |           - |           - |               576 B |
|  FindMethodCountWith5UsingGetCustomAttribute |  8,642.1 ns | 162.365 ns | 166.74 ns |      0.3204 |           - |           - |              1344 B |
|       FindMethodCountWith5UsingWellKnownName |    371.8 ns |   7.312 ns |  11.17 ns |      0.0610 |           - |           - |               256 B |

|          FindMethodCountWith10UsingIsDefined |  4,127.5 ns |  82.275 ns |  72.93 ns |      0.1526 |           - |           - |               656 B |
| FindMethodCountWith10UsingGetCustomAttribute | 13,071.9 ns | 329.667 ns | 292.24 ns |      0.4425 |           - |           - |              1904 B |
|      FindMethodCountWith10UsingWellKnownName |    477.3 ns |   9.549 ns |  16.47 ns |      0.0801 |           - |           - |               336 B |

|          FindMethodCountWith20UsingIsDefined |  6,128.2 ns | 112.359 ns |  99.60 ns |      0.1907 |           - |           - |               816 B |
| FindMethodCountWith20UsingGetCustomAttribute | 21,397.1 ns | 417.612 ns | 598.93 ns |      0.7019 |           - |           - |              3024 B |
|      FindMethodCountWith20UsingWellKnownName |    692.1 ns |  13.772 ns |  29.35 ns |      0.1173 |           - |           - |               496 B |

|          FindMethodCountWith50UsingIsDefined | 11,305.4 ns | 175.726 ns | 164.37 ns |      0.3052 |           - |           - |              1296 B |
| FindMethodCountWith50UsingGetCustomAttribute | 46,726.1 ns | 798.896 ns | 667.11 ns |      1.4648 |           - |           - |              6384 B |
|      FindMethodCountWith50UsingWellKnownName |  1,283.9 ns |  13.557 ns |  12.02 ns |      0.2327 |           - |           - |               976 B |


BenchmarkDotNet=v0.11.4, OS=Windows 10.0.17763.316 (1809/October2018Update/Redstone5)
Intel Core i7-7820HQ CPU 2.90GHz (Kaby Lake), 1 CPU, 8 logical and 4 physical cores
  [Host]     : .NET Framework 4.7.2 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3190.0
  DefaultJob : .NET Framework 4.7.2 (CLR 4.0.30319.42000), 64bit RyuJIT-v4.7.3190.0

|                                       Method |        Mean |        Error |       StdDev | Gen 0/1k Op | Gen 1/1k Op | Gen 2/1k Op | Allocated Memory/Op |
|--------------------------------------------- |------------:|-------------:|-------------:|------------:|------------:|------------:|--------------------:|
|           FindMethodCountWith5UsingIsDefined |  4,607.2 ns |    26.645 ns |    22.250 ns |      0.1831 |           - |           - |               792 B |
|  FindMethodCountWith5UsingGetCustomAttribute | 13,134.5 ns |   130.919 ns |   122.461 ns |      0.4425 |           - |           - |              1896 B |
|       FindMethodCountWith5UsingWellKnownName |    339.8 ns |    10.172 ns |     9.515 ns |      0.0625 |           - |           - |               264 B |

|          FindMethodCountWith10UsingIsDefined |  5,849.3 ns |   104.554 ns |    97.800 ns |      0.2365 |           - |           - |               992 B |
| FindMethodCountWith10UsingGetCustomAttribute | 18,868.8 ns |   188.312 ns |   166.934 ns |      0.6409 |           - |           - |              2696 B |
|      FindMethodCountWith10UsingWellKnownName |    448.2 ns |     5.050 ns |     4.477 ns |      0.0815 |           - |           - |               344 B |

|          FindMethodCountWith20UsingIsDefined |  7,676.3 ns |   140.295 ns |   117.153 ns |      0.3204 |           - |           - |              1392 B |
| FindMethodCountWith20UsingGetCustomAttribute | 30,805.5 ns |   433.344 ns |   405.350 ns |      0.9766 |           - |           - |              4297 B |
|      FindMethodCountWith20UsingWellKnownName |    699.8 ns |     8.732 ns |     7.740 ns |      0.1202 |           - |           - |               504 B |

|          FindMethodCountWith50UsingIsDefined | 13,983.6 ns |   153.433 ns |   143.521 ns |      0.6104 |           - |           - |              2592 B |
| FindMethodCountWith50UsingGetCustomAttribute | 65,309.8 ns | 1,275.028 ns | 1,612.502 ns |      2.0752 |           - |           - |              9097 B |
|      FindMethodCountWith50UsingWellKnownName |  1,216.5 ns |    23.314 ns |    21.808 ns |      0.2327 |           - |           - |               984 B |

As you can see, in both .NET Core and .NET Framework, the attribute approach (with IsDefined()) is an order of magnitude slower than the well-known name approach, and consumes 2 to 3 times more in memory. Notice that .NET Core is overall better than .NET Framework :).

Now, all is not lost:

• It's definitely possible my tests are skewed in different ways that I don't realize. If there's a technique I missed to do attribute discovery, or a different way works better, please let me know.
• There are a couple of interesting pieces of work that's been going on in CoreCLR. These don't appear to be part of .NET Core 2.2 but might be part of .NET Core 3.0. These would not be going into .NET Framework 4.8 as far as I can tell. It's also not clear if they would help out with the perf tests I did above.
  • Improve CustomAttribute - Improve CustomAttribute dotnet/coreclr#21832
  • Optimization: Reduce many array allocations in GetCustomAtttributes()'s inherited path - Optimization: Reduce many array allocations in GetCustomAtttributes()'s inherited path dotnet/coreclr#20779
  • Optimization: Further reduce allocations in GetCustomAtttributes() paths - Optimization: Further reduce allocations in GetCustomAtttributes() paths dotnet/coreclr#20795
• The design of this approach should also be considered. It may not perform as well, but we're also talking tens of microseconds and thousands of bytes, not tens of seconds and gigabytes. These differences shouldn't be dismissed, but is the trade-off that the attribute design is "better"? Or is a well-known name sufficient? The current approach in CSLA is prone to spelling mistakes, where an attribute would be safe from that. Is that a big deal?

One last thing to consider is that we may want to find a consistent way to handle features in CSLA. That is, using attributes for everything (e.g. rule registration, operation definitions, etc.) or use descriptor similar to what is done with managed backing fields. @rockfordlhotka and I had an initial discussion about this last night, and there needs to be a lot more on this topic (I'll try to post a summary in a CSLA issue soon). All that said, I think for now we may want to hold off on the attribute approach for a bit. I'm not saying we should abandon it, but let's really think hard about all these different aspects before adding this in.

[kellyethridge]

I would assume the discovery process would happen only once per class for the lifetime of the app, possibly at the same time as adding business rules. So I think it would be a minimal one-time upfront cost.

[JasonBock]

@kellyethridge yes, so even if you had 10,000 business objects, each with 6 operations, the total cost would be about 0.16 seconds for the lifetime of that app, and 19.2 MB more allocations (hopefully my math was correct on that). But I'd like to explore a more over-arching approach to business object features, which might make this conversation mood regardless of performance.

[rockfordlhotka]

My prototype idea around registration is something like this:

  public readonly static IOperation FetchMethod = 
    RegisterOperation(Operations.Fetch, o => o.MyFetchMethod);
  private void MyFetchMethod()
  {
    // do stuff here
  }

[rockfordlhotka]

@JasonBock The thing about that 10k business class scenario is that CSLA loads metadata on-demand. So in real life that 0.16 seconds would only be paid if all 10k types were used. And even then it would be amortized over the period of time it took for the app to actually use all those types.

My primary performance worry is in serverless server-side scenarios where the appdomain/equivalent is torn town frequently. But in server-side scenarios it is far more common to use a very small number of types to respond to a single inbound request.

[JasonBock]

@rockfordlhotka I was saying that you would be loading all 10,000 through the lifetime of that application scenario. Which is somewhat unrealistic - I don't think anyone is loading that diverse of a set of BOs in an app :). I was pushing the limits a bit and even with that, the perf numbers are not....well, that bad. But again, there's a potentially larger design issue here at stake.

[JasonBock]

@rockfordlhotka what if you had two fetch operations that were overloaded?

[ajj7060]

I like this idea; it would overcome having to use the new keyword to hide some of the DP_XYZ (e.g., DataPortal_Execute) when the operation needs to be async, and we can properly name the methods with an Async suffix.

[tdyocum]

I really like this idea!