[♻️ C# core using Schema Classes]

Scope

The following scope will try to solve several issue at the same time such as:

• C# code is messy (some object from StruSoft namespace other from FemDesign) and complicated for C# user without experience
• stop losing data
• hide property that should be private
• serialise/deserialise file will look the same as we will use the default value from xsd schema
• our API will become indipendent from FEM-Design updates and therefore easier to mantain
• the object model can become the MASTER model for StruSoft so that can be use for other services (not a priority)

Refactoring

The main idea is to create a facade on StruSoft.Interop.StruXml.Data

Create an object

Example on how we will do it
The user will use our own object PointSupport but internally we will reference the input to the StruSoft.Interop object

public partial class PointSupport
{
    private StruSoft.Interop.StruXml.Data.Point_support_type _pointSupportType;

    public string Name
    {
        get
        {
            return this.point_Support_Type.Name;
        }
        set
        {
            this.point_Support_Type.Name = value;
        }
    }

    public Point3d Position
    {
        get
        {
            var x = this.point_Support_Type.Position.X;
            var y = this.point_Support_Type.Position.Y;
            var z = this.point_Support_Type.Position.Z;
            return new Point3d(x,y,z);
        }
        set
        {
            this.point_Support_Type.Position = new StruSoft.Interop.StruXml.Data.Point_type_3d
            {
                X = value.X,
                Y = value.Y,
                Z = value.Z
            };
        }
    }
}

The serialisation and deserialisation will always occur using the StruSoft.Interop object

Testing

Testing the API is crucial for ensuring its reliability, functionality, and security.
Testing that we can consider:

Unit Testing
Write tests for each individual component, function, or method in your API.
Ensure test coverage is high, covering critical paths and edge cases.

Which tool❓
Testing -> MS Test, xUnit.net
Code coverage tools -> Coverlet

Performance Testing
Measure the response time and throughput of your API under various loads.
i.e. Model should not take 20 seconds to serialise/deserialise

Which tool❓

Documentation Testing
Ensure that your API documentation is accurate and up-to-date.
Test code examples provided in the documentation to verify their correctness.

Which tool❓

Regression Testing
Continuously run tests to ensure that new changes don't introduce regressions.
Use Continuous Integration/Continuous Deployment CI/CD pipelines to automate testing and deployment processes.

NOTE regression / we have a service to call femdesign in the cloud

Which tool❓

User Acceptance Testing (UAT)
Involve users to test your API in a real-world environment.
Collect feedback and make necessary improvements based on user experience.

---

Documentation

Documentation should be automatic generated using the xml tags such as <summary>, <code>

https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/xmldoc/#tools-that-accept-xml-documentation-input

References
https://spatialslur.gitlab.io/docs/api/index.html
https://mcneel.github.io/rhinocommon-api-docs/api/RhinoCommon/html/N_Rhino.htm

Plan

We will start a new project called FemDesign.NextCore.
FemDesign.Gh will still reference the old FemDesign.Core until we are not ready with FemDesign.NextCore.
Later will need to start updating the grasshopper component to reference the new code.

Using Coverlet we will make sure to test the code since the beginning

Cons
There is an overlap period where 2 femdesign.core will exist. If a grasshopper user require a bug fix or feature update, we can quickly do it using the old FemDesign.Core

Note

FdScript will not change

Goals

Let's start giving the possibility to create a bar with FemDesign.NextCore and collect feedback from users

• geometry
• bar class
• section class
• material class
• support
• load case
• load combination
• line load
• point load

Start with the issue's plan for the new FemDesign.NextCore project and compare it with the existing FemDesign.Core and StruSoft.Interop.StruXml.Data usage. The stated goals cover a broad object-model refactor, testing strategy, documentation generation, and multiple model classes, but no files, tests, or first implementation entry point are identified. Done would require an agreed scope and working NextCore coverage for the selected goals.