Enum struct? Value object that behaves like an Enum

Question

I wonder how you approach this problem.

I have two taxes that may apply to my products. I specifically want to avoid storing Taxrates in the database, but still I can change them in a central place (for example, Taxrate from 20% to 19%, etc.).

so I decided that it would be great if they just compiled into my application (it’s internal). The problem is that I want to not only know the tariff, but also the name of the tax rate.

I could go with Enum, which displays the value. But then I will have to create some method that extracts the German name of this Taxrate for the English value enum (I write my code in English, the application is in German).

I thought about just using hard-coded objects to reflect this,

public interface Taxrate { string Name { get; } decimal Rate { get; } } public class NormalTaxRate : Taxrate { public string Name { get { return "Regelsteuersatz"; } } public decimal Rate { get { return 20m; } } } 

But then I will have to create some kind of list containing two instances of these two objects. Performing this static action may work, but still I will need to save some list. I also need to find a way to map my POCO domain object to this, because I doubt that NHibernate can create an instance of the desired object depending on the value in the field.

This is really not the case, and I think something is missing here. Hope someone has a better solution, I can’t think about it.

Greetings Daniel

Ps: also, please repeat this question, if you find something suitable, I can’t think of more meaningful tags right now.

Answer 1

EDIT: Please note that here the code can be easily shortened if you have a private constructor with a tax rate and name. I assume that in real life there may be actual behavioral differences between tax rates.

It looks like you want something like Java enums.

C # makes this pretty difficult, but you can do it to some extent using private constructors and nested classes:

  public abstract class TaxRate { public static readonly TaxRate Normal = new NormalTaxRate(); public static readonly TaxRate Whatever = new OtherTaxRate(); // Only allow nested classes to derive from this - and we trust those! private TaxRate() {} public abstract string Name { get; } public abstract decimal Rate { get; } private class NormalTaxRate : TaxRate { public override string Name { get { return "Regelsteuersatz"; } } public override decimal Rate { get { return 20m; } } } private class OtherTaxRate : TaxRate { public override string Name { get { return "Something else"; } } public override decimal Rate { get { return 120m; } } } } 

You will probably need some kind of static method in TaxRate to return the correct instance based on the name or something else.

I don’t know how easy it fits into NHibernate, but hopefully it helps to some extent ...

As noted in the comments, this is pretty ugly - or at least it can become pretty ugly when you have many different meanings. Partial classes can help here:

 // TaxRate.cs public partial abstract class TaxRate { // All the stuff apart from the nested classes } // TaxRate.Normal.cs public partial abstract class TaxRate { private class NormalTaxRate : TaxRate { public override string Name { get { return "Regelsteuersatz"; } } public override decimal Rate { get { return 20m; } } } } // TaxRate.Other.cs public partial abstract class TaxRate { private class OtherTaxRate : TaxRate { public override string Name { get { return "Something else"; } } public override decimal Rate { get { return 120m; } } } } 

You can then create a project file to show nested classes as children of an outer class, as shown in this SO question .

Answer 2

I would do it like this:

 public class TaxRate { public readonly string Name; public readonly decimal Rate; private TaxRate(string name, decimal rate) { this.Name = name; this.Rate = rate; } public static readonly TaxRate NormalRate = new TaxRate("Normal rate", 20); public static readonly TaxRate HighRate = new TaxRate("High rate", 80); } 

Thus, it would be easy to use it - just access static members of TaxRate , such as enum values. To use it in NHibernate, you will need to create your own class of type NHibernate (see the documentation for it), but it is not so difficult. I already did it already.

Answer 3

Why not save tax rates in the application configuration, for example, in the web.config or app.config file? These are simple XML files that have a section in which you can specify user parameters with a key and value. For instance:

 <appSettings> <add key="BaseTaxRate" value=20"/> <add key="HigherTaxRate" value=40"/> </appSettings> 

You can simply restore them in your application:

 string baseTaxRate = ConfigurationSettings.AppSettings["BaseTaxRate"]; 

Thus, they are easy to change and do not require re-compilation and redeployment of your application.

Obviously, you can also save tax rate names as additional parameters in the configuration file.

Answer 4

I have to say that I find the idea of ​​using nested classes somewhat fanciful for what seems to me a basic requirement.

What is wrong with storing bets in a database (or other persistence medium, such as an application configuration file)? I would think that you want to have a unique identifier for each tax rate used to link between products and tax rates.

So, you will have a TaxRate class with Id / Description / Rate (*). You can download a dictionary with all possible values ​​to quickly search for speed / description by identifier.

(*) In a multilingual application you will need to find a localized description for each Culture / Id pair - either from the second table in the database, or from resources, etc.

In any case, posting rates seem wrong - especially now that governments are playing with tax rates to try to boost their economies.

Answer 5

I know that this is against the basic premise of your question, but I would like to express some thoughts on this issue.

Although at the moment this may seem like a logical decision to avoid forfeiting VAT and tax rates in the database, the time will be wrong. Firstly, you should always be able to retrieve the data as it was at the moment, and for this you need to manage the versions of bets.

As you know, the only constant is change. Tell me, bid changes (they will). If you lose access to the source, you cannot provide the proper service. If rates were to be split from flat VAT to different rates, updating the system would be even more difficult.

This problem is not something up though. The United Kingdom reduced VAT from 17.5% to 15% from December 1. Many people are stuck with old software without the ability to update rates. Please do not make this mistake (and splitting bets in the database will also bring many other improvements).