0

I'm having a dilemma where I would need to implement a better way for our Project Model with dynamic property depending on the country.

So what happen in our application we have dynamic fields for a projects depending which country it is. For instance the project model in the Australia has Foo but not in the project model in the America.

public class ProjectAustralia 
{
 public string Bar {get; set;}
 public string Foo {get; set; }
}

public class ProjectAmerica 
{
 public string Bar {get; set; }
}

My currently implementation is I defined everything in one class however this will get bigger as we will be implement other countries with their own properties for the ProjectModel.

What would be the best way to do this? Thank you

Update: To add more details, the application is a project management tool for researchers so for each country they have their own Project form which has different fields. For the base of this Project it has Name, Stage, Description, Keywords and the rest depends on the country which a project is being used. We also use NoSQL to dynamically save this Project entities. I could not discuss further because of the nature of the application. I hope this helps.

  • the best way will depend on lots of things, can you add more detail about the type of application, what data the propeties contain and what the class is for? – Ewan Sep 6 '18 at 8:50
  • @Ewan I have updated the question. I hope this helps. :) – rpmansion Sep 6 '18 at 9:08
  • mind if i edit your objects to include the property names – Ewan Sep 6 '18 at 9:11
  • hmm wait, what are Foo and Bar – Ewan Sep 6 '18 at 9:12
  • @Ewan it's just an example :) – rpmansion Sep 6 '18 at 9:13
2

One solution is to use many interfaces:

interface IFoo
{
    string Foo {get; set; }
}

interface IBar
{
    string Bar {get; set; }
}

and to have the classes implement the relevant interfaces:

public class ProjectAustralia : IFoo, IBar
{
    public string Bar {get; set;}
    public string Foo {get; set; }
}

public class ProjectAmerica : IBar
{
    public string Bar {get; set; }
}

That way, you limit the dynamic aspects to serializing/deserializing from eg JSon in your NoSQL database.

For the rest of the system, simple type checks can be used to determine which features the class has:

if (project is IFoo fooProject)
{
    // do something with fooProject.Foo
}

Whether this approach is practical for your situation depends on how any properties are involved. For example, having to list the 50 interfaces that a class implements would become hugely burdensome.

If you have many different properties, then an alternative approach is to have just one project class and to use a dictionary to hold those properties:

class Project
{
    public string Name {get; set}
    public string Stage {get; set}
    public string Description {get; set}
    public string Keywords {get; set}
    public Dictionary<string, string> Properties { get; set }
}

and to then add Foo, Bar etc to the dictionary. This offers less boilerplate code and more flexibility. But it loses runtime type safety as there's nothing to stop Foo being added to America for example.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.