Инструментарий для DSL / пользовательских типов в C #?

Question

Итак, у меня есть приложение C # с пользовательской иерархией типов, глубиной ~ 4 слоя.

Эта многоуровневая структура обеспечивает чистую реализацию проверки данных и распространения событий изменения.

Примером может быть: DocumentNameValue -> NameValue - > StringValue -> BaseDataValue.

Система работает нормально, но с учетомвсе уровни косвенности, производительность серферов.В абсолютном выражении это не огромный успех, но он суммируется.

Чтобы пояснить, проблема с производительностью, кажется, является результатом вложенных вызовов, которые происходят при доступе к данным.

Например, вызов DocumentNameValue.setValue("test.doc") приведет к тому, что каждый уровень иерархии будет выполнять определенные проверочные тесты на входе.Они начинаются у основания и движутся вверх.Различные события также проводятся по пути.Значение фактически «хранится» в основании иерархии, если это имеет смысл.

Поскольку все, что я действительно сделал, это определил строгую иерархию типов, существует ли рекомендуемый метод дляиз:

1. Преобразовать этот код C # в "плоский" высокопроизводительный эквивалент?(Во время выполнения или во время компиляции)
2. Или, возможно, лучше создать DSL, который бы просто выдавал эквивалентный список типов / объектов?

Общая цель двоякая: Используйте строгие типы, характерные для моей проблемной области приложения, предоставьте чистое место для размещения моих правил проверки.

Может кто-нибудь дать несколько советов / предложений?Я все делаю неправильно?

Спасибо

Answer 1

Мой первый инстинкт заключается в том, чтобы спросить, откуда вы знаете, что это является причиной вашего падения производительности.Вы запускали профилировщик?

Мой второй вопрос - попросить образец кода.Отражено ли это наслоение через ООП (наследование)?

Из того, что я понимаю, вы используете разные типы для представления разных задач - и это хорошо.Вы создали что-то вроде ViewModel / Model / DataModel, что является довольно стандартным.

---

Учитывая ваш комментарий, я предлагаю вам загрузить пробную версию ANTS Performance Profiler и использовать ее для профилирования медленной реализации;он точно скажет вам, какие методы используются дольше всего, и позволит вам количественно оценить результаты изменений.

Я бы не советовал разрывать ваш многоуровневый подход, если только приложение не очень простое.Изучение того, как правильно внедрить многоуровневую систему, позже может принести вам пользу.

Answer 2

Система работает нормально, но учитывая все слои косвенности, производительности серферы. В абсолютном выражении это не Огромный успех, но это в сумме.

Вероятно, нет. Скорее всего, вам необходимо пересмотреть это предположение.

Часто ли это делается?

Нет. Потому что в этом нет необходимости. Создание иерархии наследования (по сравнению с классами, которые не наследуют другую) не оказывает существенного влияния на производительность в огромном, огромном, огромном, подавляющем большинстве приложений. Кроме того, если ваш проект является тем, на который в значительной степени повлияло использование наследования, вы, вероятно, уже приняли неправильное решение в отношении управляемого языка.

Answer 3

Для пояснения проблема с производительностью, по-видимому, является результатом вложенных вызовов, которые происходят при доступе к данным.

Например, вызов DocumentNameValue.setValue ("test.doc") приведет кна каждом уровне иерархии выполняются определенные проверочные тесты на входе.

Вы максимально абстрагировались и, следовательно, потеряли контроль над доступом к данным.Независимо от того, являются ли типы плоскими или нет, это не влияет на то, какой sql выдается или ввод-вывод в базе данных.

Удалите доступ к данным из абстракции или понизьте непредвиденные затраты на ввод-вывод для каждого установщика.Получить Ленивый.