We are building a system that will require a high level of runtime customization. The core functionality of the system is a generic grid and record editor. There are several system defined types (e.g. Contact and Message).

End users should be able to create several lists of Contacts and of Messages. Each list may have different custom fields. All these definitions are thought to be persisted in a separate configuration database so that it can be loaded before the actual data domain is built.

I have done some testing and realized that it is very easy to add these custom fields to the Entities using DefineField in the OnDefinitionsBuilt method of a DO.NET Module. The problem is that we are using dynamic LINQ for our grid and querying, and when we pass in the name of the custom field, it fails since the .NET Property does not exist (DLINQ uses reflection to bind to the actual property defined in the class).

This led me to think that it might be easier to generate custom types at runtime (basically one type for each list) and do a compile before the domain is built, similar to how the ProxyAssembly in previous versions of DO worked. This would ensure that each type is a "proper entity class". We could use dynamic LINQ and do not have to distinguish between custom and system fields when handling querying, loading and saving.

Another handy thing is that we could pretty easily extend this system to support custom logic by overriding methods and put in custom code (though in most cases it would probably be better to solve this using an OO design pattern).

I didn't finish the runtime compile experiment since I didn't have time to look into executing PostSharp on the dynamically compiled assemblies. One main issue I thought of is then licensing of DO.NET and/or PostSharp. It would have to do this compilation on one or more servers. How would that work? Is there a runtime / redistributable license that handles compilation of custom assemblies?

The reason for writing this here, is that I would like to get some feedback and recommendations on what to do. Is there a way of making DLINQ work with fields that are not properties? As far as I can see, the entity.GetProperty() methods cannot be translated by the LINQ translators. If that had worked, we could use that instead of DLINQ, meaning that we do not really need to have the fields defined as .NET Properties.

A more simple (but limiting) way of doing this would be to just limit the number of custom fields we want to support and call them CustomString[1-10], CustomDate[1-10] etc. Then in the customization configuration we would need to map the configured fields to one of these custom fields.

I'd appreciate any feedback and tips on how to resolve this.