Design and Architecture

Log.Verbose("Here's a Verbose message.");
Log.Debug("Here's a Debug message. Only Public Properties (not fields) are shown on structured data. Structured data: {@sampleData}. Simple data: {simpleData}.", structuredData, simpleData);
Log.Information(new Exception("Exceptions can be put on all log levels"), "Here's an Info message.");
Log.Warning("Here's a Warning message.");
Log.Error(new Exception("This is an exception."), "Here's an Error message.");
Log.Fatal("Here's a Fatal message.");

private void DoSomeProcessing(string inputFile, bool someParam)
{
    Log.Information("Inside DoSomeProcessing");

    if (someParam)
    {
        Log.Warning("Just letting you know that 'someParam' = true");
    }

    if (string.IsNullOrEmpty(inputFile))
    {
        Log.Error("inputFile is null");
        throw new ArgumentNullException(nameof(inputFile));
    }

    try
    {
        Log.Information("Doing the processing");
        var a = 10 + 20;

        Log.Information("Doing some more");
        var b = 10 + a;

        Log.Information("And even more");
        var v = a + b;
    }
    catch (Exception e)
    {
        Log.Fatal("Something terrible happened here!");
        throw e;
    }
}

• Lift - a lift operation
  • LiftObject - the thing to lift
    • Weight - weight of the object, double
    • Cog - centre of gravity, position in X, Y, Z
    • Liftpoint - point where you can attach rigging, can have up to four
      • Id: Id, local to Lift
      • Position: position in X, Y, Z
  • Hook - a hook, can have up to two
    • Position - X, Y, Z position of the hook
    • Type: 1, 2, 3, 4 leg hook
    • Leg - a leg between a hook, and a piece of rigging, can have up to 4 legs per hook
      • Id - Id local to hook
      • LiftPointId

1. Lift is aggregate, since you can't modify any of the sub objects without needed to see if it is still consistent with the other ones (i.e. changing the cog changes the validity of the lift points). It's also an entity, since we want to be able to model multiple lifts.
2. LiftObject is an entity, although I expect that it can never be referenced by more than one lift (since modifying this entity would have implications to all connected lifts)
3. Weight and Cog are clear value objects
4. Hook is a (local) entity
5. Leg is a (local) entity

• Common - contains interfaces describing the models
• Designer - contains concrete implementations of the models in Common, used for creating and changing the models
• Solver - uses the interfaces in common to calculate the loads on the hooks and legs

Quote:

... The issue with the MVVM pattern is that it can inadvertently lead to apps that have too many layers and too many allocations.

... But strict adherence to any variation of the pattern can lead to apps with a lot more overhead than can be justified.

... consider putting event handlers in your code-behind ....

• "in which roughness should I store permissions?"
• "in which format should I store my permissions?"
• "should I use RBAC, UBAC, ACL,... and how would I concretely implement them, cleanly?"
• "How do I combine all that with a system that contains several individual organizations with their own set of permissions?"

• A cook book.
• Answers that just say "use this or that, because it's the standard"
• Some "hip" book after which you nod, say "yes, aha, I see", but didn't really make you smarter.