C# class question

Question

Hi,

 I have three schemas in my database accordingly CustomerA, CustomerB,Common. The CustomerA, CustomerB schemas will have same set of tables. the reason to have like two separate tables to provide the data privacy b/w customers and each schema will be secured by database users. Will be using individual connection string for each customer. (Same database with different schema with individual connection string )

Assume I have c# class for each schema and both classes will have same set of methods but returns customer specific data. Based on login information I will know which Customer logged in. But I am struck how to call the customer class based on login info dynamically.

tried the below sample code. but its not working as expected. please help me sort the issue.

namespace FactoryPattern
{

 public interface ICommon
    {
        string GetCustometName();

    }
}

namespace FactoryPattern
{

 class CustomerA : ICommon
    {
        public  string GetCustometName()
        {
            return "i am CustomerA";
        }
    }
}

namespace FactoryPattern
{

 class CustomerB : ICommon
    {
        public string GetCustometName()
        {
            return "i am CustomerB";
        }
    }
}

namespace FactoryPattern
{

public abstract class SomeBase { }


    public sealed class Factory
    {
        private static readonly Dictionary<string, Type> TypeLookup;

        static Factory()
        {
            // You could iterate over additional assemblies if needed
            // the key is assumed to be the name of the class (case insensitive)

            TypeLookup = typeof(Factory).Assembly.GetTypes()
                .Where(t => t.IsClass && !t.IsAbstract && typeof(SomeBase).IsAssignableFrom(t))
                .ToDictionary(t => t.Name, t => t, StringComparer.OrdinalIgnoreCase);
        }

        public SomeBase Create(string name)
        {
            Type t;
            if (TypeLookup.TryGetValue(name, out t))
            {
                return (SomeBase)Activator.CreateInstance(t);
            }
            throw new ArgumentException("Could not find type " + name);
        }
    }
}

namespace FactoryPattern
{
    internal class Service
    {
        private Factory factory = new Factory();
        private dynamic _obj;

        public Service(string Account)
        {
            switch (Account)
            {
                case "CustomerB":
                    _obj = factory.Create("CustomerA");
                    break;

                case "CustomerB":
                    _obj = factory.Create("CustomerB");
                    break;
            }
        }

        public string CustomerName()
        {
            return _obj.GetCustometName();
        }
    }
}


 class Program
    {
        static void Main(string[] args)
        {

            Service service = new Service("CustomerA");
            service.CustomerName();

	    Service1 service = new Service("CustomerB");
            service.CustomerName();
        }
    }

Answer 1

Do the customers have the same data in both tables? If so then partitioning the data into separate schemas is really a database design, not an architectural one. If the data is different then I'm curious how your app is going to make any of this overly usable. For example, supposed CustomerA has an Address field but CustomerB does not. Is your UX going to be coded to handle either set of data and then determine which to show based upon some indicators? That seems like a lot of work when you could just store the same data for both sets of customers and then just pull from the appropriate tables instead.

There are many different ways to go here and since we don't have insight into all your requirements then we would be guessing about what might or might not work. At a minimum I would recommend introducing an interface or base class Customer that contains the shared set of data. Return this from anything in the system that needs a customer. Create derived types for each unique customer type that expands on the data to expose the specifics. This is pretty standard for normalizing data such as in authentication systems, database providers, etc.

If the data between both are similar then consider exposing all the data from your base Customer type and then just fill in what is available depending upon which customer you're dealing with. For example customer A might set the Address property and the SupportsAddress property but customer B would not since it doesn't support an address. This normalizes the data and tends to make it easier to build more generic UXs from but as the differences expand then it becomes harder to maintain.

Answer 2

Rather than duplicate classes, I add support to setting the default schema name in the DbContext during OnModelCreating

if the tables can vary by schema, then as suggested use separate classes but with defined interfaces for each class.