Comments by Mort Sjostrom (Top 2 by date)

Mort Sjostrom 10-Apr-16 16:47pm View

Thanks Sergey and yours is most helpful insight into a namespace that I've only begun to learn. I'm considering your idea in Solution 1.

One challenge is that over time new properties are introduced (and removed) on my inherited project and I'm very open to other ideas.

I have considered a dictionary which introduces obscure requirements with regard to model binding and a need to specify explicit .Key & Value parameter s. With that, and apart from any one discipline, I've been exploring duck-type dynamics or possibly writing a binder. For now I remain curious about dynamics.

Mort Sjostrom 10-Apr-16 15:47pm View

I plan to use it for a small set of MVC5 Views which represent basic settings / options for the web application on which I am developing. Settings that indicate how and what content is rendered, enable/disable various features, how various calculations should compute, default order of grids, more, etc.

These "settings" are stored in one table and depending on the web app feature, various records are pulled from that table and mapped to a model which is bound to a view.

There are so many groups of settings coming from the same source, that I thought I should create one "settings" model wherein the properties would be dynamic, and would not have to create fixed models/dto's/maps for each group of settings. hope that makes sense and open to ideas.