В моей системе мои клиенты должны иметь возможность получать список объектов, представляющих состояния / контекст службы. Скажем, у вас есть следующее действие, выполненное данным клиентом для извлечения контекста:
List<someObjects> aList = GetListOfObjects();
Теперь клиент может получить aList, но он также может изменить этот список перед отправкой его обратно через канал, который Я хотел бы предотвратить (поскольку это не будет представлять систему больше). Поэтому клиент не должен иметь возможность:
aList.RemoveAt(1); // Should not be possible to remove object from this list
SetListOfObjects(aList);
Я думал, что смогу создать класс «aList» только для чтения, но я все еще хочу иметь возможность изменять свойства объектов, поэтому я не это правильно.
Одна идея состоит в том, чтобы фактически создать класс, где все объекты из списка aList будут свойствами. Таким образом, класс навязывает структуру, которая не может быть изменена клиентом. Тем не менее, контекст системы может варьироваться (в зависимости от используемого оборудования), что означает, что этот класс должен быть создан динамически.
Однако я не хочу терять безопасность типов и, следовательно, предпочел бы не использовать динамический c или раскрыть Objects.
Может быть, использовать что-то в этом роде - хорошая идея здесь , см. ответ от Даниелс. Но я не уверен, что при этом безопасность типов будет сохранена.