C# – Designing Models for a Generic Service Layer

Architectureasp.netcweb servicesweb-development

We are building a web interface to a tiered membership system, which will interface with a third-party CRM web service for the creation and management of accounts. The web service, unfortunately, is not yet built; however, we need to begin work.

I have created an interface, IMembershipService, in which I am beginning to define "best-guess" prototypes, so we can begin building our User Controls. Most of these methods will return some data bundled in a Model object, e.g.:

ContactModel GetContact (string userId);

When the web service methods become available, I will create a concrete implementation of IMembershipService that will wire up the controls to the web service.

The problem I have is that I don't yet know whether the web service will consist of:

calls returning complex objects; e.g. a User object with a nested Membership object, which, in turn, has a nested PaymentMethod object
simple calls for specific pieces of information; e.g. String GetUserMembershipType (string userId);

This is causing me to have trouble specifying the structure of the models and interface, which is causing problems for the developers beginning work on the User Controls:

If the service returns complex objects, I don't want my IMembershipService methods to be too simple, forcing me to use multiple web service calls where it is not necessary.
If the service consists of simple calls, I don't want to have a load of complex models defined that I then can't implement, thereby having to do a load of refactoring.

In theory, creating IMembershipService should allow me to abstract away from the actual nature of the web service, but the fact that each call to a method in IMembershipService will, ultimately, result in a web service call, thereby adding overhead, is making this difficult to spec.

How can I design my models and IMembershipService in order to minimize the amount of refactoring I have to do when the nature of the web service becomes less elusive?

Best Answer

Decide on the most convenient interface for your application, and define an interface according to that. What information will you need, and in what discrete units? Define models according to those units.

After all is said and done, that's the information you need. Let the implementation later be an adapter to the webservice. It won't matter if it needs to do multiple callstothe webservice or not - that's just an implementation detail.

Related Solutions

Database Practices – Why Put a Simple Query into a Stored Procedure in a Web Service?

The idea behind this is probaby to keep a low degree of coupling. Your application talks to the web service only, and the web service talks to stored procedures only. There are no SQL statements in your front-end code, only web service calls; and there are no SQL statements other than stored procedure calls in the web service. There are several advantages to this:

It's more maintainable. All the SQL queries are in one place, so you never have to go hunt them down (and possibly overlook a crucial one).
Each component (web service, front-end, database) can be swapped out individually for testing and debugging.
Many types of errors remain contained within one module, e.g. there cannot be any SQL syntax error in the front-end, because it doesn't contain any SQL at all.
If at some point you need to migrate to newer versions of your platform components, you can migrate each component individually, mitigating risks. For example, you may choose to move the front-end to a newer .NET, while the database server still runs the old version.
It's more scalable. If at some point you decide to split database and front-end over different servers, you can - just configure the front-end to talk to a different host for the web service, or configure the web service to connect to a different database host, or even both (which would create a physically separated three-tier structure). Additionally, you can implement caching and load balancing at several levels, including the intermediate web service. And if at some point you decide you need to shard your database, you can probably implement the required logic in the web service, without affecting the front-end at all.

And there's the responsibility thing: By moving your actual queries to the database, they become part of the DBA's realm. If you have a decent DBA, he's probably much better at SQL than you are (especially when it comes to obscure yet business-critical edge cases that can have dramatic effects on performance), and it's a good thing to have him at least check your SQL before it goes into production.

C# Web Development – Sharing Methods and Properties Between Custom Web Controls

As I can't use true multiple inheritance in C#, how would I design this to be able to share the methods and properties?

This is the right way to share the methods and properties. But:

The trouble now is that in my extendedTextBox class I can't cast my extendedTextBox as a 'BaseExtendedControl' to use the extension methods, as the extendedTextBox inherits from the standard TextBox class like this:
public class ExtendedTextBox : TextBox, IExtendedControl
so there's no common base to cast ExtendedTextBox as 'BaseExtendedControl' as it doesn't inherit from it.

Yes, you're right there is no common class, but you can solve the problem by casting to the IExtentedControl interface which is common to your classes and contains the methods that you need. So what about:

public static class ExtendedControlHelper
{
    public static void AddRequiredFieldValidator(this IExtendedControl control)
    {
        control.rfv = new RequiredFieldValidator();
        control.rfv.ErrorMessage = control.RequiredMessage;
        ConfigureAndAddValidator(control, control.rfv);
    }

    public static void ConfigureAndAddValidator(this IExtendedControl control, BaseValidator validator)
    {
        validator.ControlToValidate = control.ID;
        validator.Display = ValidatorDisplay.Dynamic;
        validator.CssClass = "validationMessage ";
        validator.CssClass += control.ValidatorCssClass;
        validator.EnableClientScript = control.ClientScript;
        control.Controls.Add(validator);
    }
}

I don't think you need to implement the IExtendedControl interface in the ExtendedControlHelper class. Moreover I corrected the grammar of the interface name from IExtendendControl to IExtendedControl.

EDIT :

Another solution could be to use the dynamic keyword. The dynamic keyword is like object but the type is checked at run time instead of compile time:

public static class ExtendedControlHelper
{
    public static void AddRequiredFieldValidator(this dynamic control)
    {
        //...
    }

    public static void ConfigureAndAddValidator(this dynamic control, BaseValidator validator)
    {
         //...
    }
}

The dynamic type doesn't exist at run time because it's solved by the compiler, so if you write this: myExtendedTextBox.AddRequiredFieldValidator(); the method is solved as

//...
public static void AddRequiredFieldValidator(this ExtendedTextBox control)
{
    //...
}

and so on. So the type can change continuously at run time.

For more informations give a look here.

Best Answer

Related Solutions

Database Practices – Why Put a Simple Query into a Stored Procedure in a Web Service?

C# Web Development – Sharing Methods and Properties Between Custom Web Controls

Related Topic