We do have some work in this area before we are perfect - the auto generated Forms UI (the add/edit UI you get for free when defining a new data type) have no true N:M features, so you need to define UI at a lower level which require a lot more work. There
are some pseudo N:M features you could consider, see below.
Once you are writing UI code that is dependent on some data types (data types in Composite C1 are CLR types, interfaces) you probably would like to have those data type defined in C#, rather than having the types auto generated by Composite C1 at runtime.
I won’t dive into details here, but leave with a few relevant links.
Defining data types using code:
Building custom applications:
The may be situations where “many to many” can be implemented using a simple string field, populating it with a comma separated list of keys. There are visual tooling available for this, making this the easy many-to-many implementation. This
may work well in many situations, perhaps with somne custom caching / wrapping.
Composite C1 ships with two widgets for string fields, that let users select multiple elements and then store the selection in a single string field:
Composite.Widgets.String.Selector (with param Multiple=True).
Also, if you use the build in Get(Data)Xml functions, and build up predicates for filtering data you will find functions like
Composite.Utils.Predicates.StringInCommaSeparatedList which will search a string field containing comma separated values for a specific string or GUID.
There isn’t much computer science glory in this approach, but as the features are in Composite C1 is right now, this can save you a whole lot of code.