CODEWITHSUNDEEP
c#domain-driven-designlanguage-designdsl
nonot1
nonot1

Reputation: 2808

Toolkit for DSL / custom types in C#?

So, I've got a C# application with a custom types hierarchy that's ~4 layers deep.

This layering exists to provide a clean implementation of data validation and change event propagation.

An example would be: DocumentNameValue -> NameValue - > StringValue -> BaseDataValue.

The system works fine, but given all the layers of indirection, performance surfers. In absolute terms, it's not a huge hit, but it does add up.

To clarify, the performance issue seems to be as a result of the nested calls that happen on data access.

For instance, calling DocumentNameValue.setValue("test.doc") will result in each layer of hierarchy running certain validation tests on the input. These start at the base and move up. Various events are also fired along the way. The value is actually "stored" at the base of the hierarchy, if that makes any sense.

Since all I've really done is define a strict hierarchy of types, does there exist a recommended method to do either of:

  1. Transform this C# code in to a "flat" high performance equivalent? (Run-time or Compile-time)
  2. Or, perhaps better, construct a DSL that would just spit out the equivalent list of types/objects?

The overall goal is twofold: Have strong types that are specific to my application problem domain, provide a clean place to put my validation rules.

Can anyone provide some tips / suggestions? Am I doing this all wrong?

Thank you

Upvotes: 1

Views: 267

Answers (3)

Amy B
Amy B

Reputation: 110071

To clarify, the performance issue seems to be as a result of the nested calls that happen on data access.

For instance, calling DocumentNameValue.setValue("test.doc") will result in each layer of hierarchy running certain validation tests on the input.

You have abstracted to the maximum and therefore lost control of your data-access. Whether the types are flattened or not does not change what sql is issued or IO spent in the database.

Move the data access out of the abstraction, or suffer unexpected IO costs on every setter. Get Lazy.

Upvotes: 0

STW
STW

Reputation: 46366

My first instinct is to question how you know this is the reason for your performance hit. Have you ran a profiler?

My second question is to ask for a code-sample. Is this layering reflected via OOP (inheritance)?

From what I understand you're using different Types to represent different concerns--and this is good. You've built something like ViewModel / Model / DataModel, which is quite standard.

Given your comment, I suggest you download a trial of ANTS Performance Profiler and use it to profile the slow implementation; it will tell you precisely what methods are taking the longest, and will let you quantify results of changes.

I wouldn't suggest tearing apart your layered approach just yet, unless the application is very simple. Learning how to cleanly implement a layered system can pay off with your sanity later.

Upvotes: 3

quentin-starin
quentin-starin

Reputation: 26628

The system works fine, but given all the layers of indirection, performance surfers. In absolute terms, it's not a huge hit, but it does add up.

Probably not. You most likely need to reexamine this assumption.

Is this sort of thing frequently done?

No. Because there is no need. Creating an inheritance hierarchy (versus classes that do not inherit another) does not meaningfully affect performance in the vast, vast, huge, overwhelming, vast majority of applications. Furthermore, if your project is one that is meaningfully affected by the use of inheritance, you've probably already made the wrong decision going with a managed language.

Upvotes: 1

Related Questions