Question

Summary: I want to know the best design for creating cross-platform (eg. desktop, web, and Silverlight) classes in C#, with no duplication of code, with the pros and cons of each design.

I’m often writing new, useful classes for one application domain; there’s no reason why they won’t work across domains. How can I structure my code to make it ideally cross-platform?

For example, let’s say I wanted to make a generic “MyTimer” class with an interval and on-tick event. In desktop, this would use the built-in .NET timer. In Silverlight, I would use a DispatchTimer.

Design #1 might be “create a class and use pre-processor directives for conditional compilation,” eg. “#IF SILVERILGHT …”. However, this leads to code that is less understandable, readable, and maintainable.

Design #2 might be “create subclasses called DesktopTimer and SilverlightTimer and consume those from MyTimer.” How would that work?

While this is a trivial case, I may have more complicated classes that, for example, consume platform-specific classes (IsolatedStorage, DispatchTimer, etc.) but aren’t directly replacing them.

What other designs/paradigms can I use?

Answer 1

I would suggest writing Interfaces that you would simply implement for your platform specific code. Then, the interfaces assure that your code will respect the contracts given by your interface, otherwise there will be a code break (if one member is not implemented).

Besides, within this library where resides your specific timer classes, to stick to your example, I would create a class for each platform, thus using the DispatchTimer for Silverlight, and the built-in .NET timer for the desktop version.

In the end, you would end up using only one interface that only its implementers know how to deal with the contract specifically to your underlying platform.

EDIT #1

Conditonal design is not an option for a good design. Here is a tool that will help you deal with the Dependancy Injection, that is called Unity Application Block, and is used to deal with such scenario like yours.

You only use an XML configuration that is very versatile to "tell" what has to be instantiated when this or that interface is needed. Then, the UnityContainer consults with the configuration you have made, and instantiate the right class for you. This assures good design approach and architecture.

EDIT #2

I’m not very familiar with Dependency Injection, and not at all familiar with Unity Application Block. Can you point to some resources or explain these a bit further?

1. Microsoft Enterprise Library 5.0 – April 2010;
2. Microsoft Unity 2.0 – April 2010;
3. Microsoft Unity 2.0 Documentation for Visual Studio 2008;
4. Are there good tutorial/walkthroughs for unity that don’t use configuration files? (SO question on the topic that should provide valuable hints to start with Unity);
5. Specifying Types in the Configuration File;
6. Walkthrough: The Unity StopLight QuickStart;
7. Walkthrough: The Unity Event Broker Extension QuickStart.

I think these resources shall guide you through your learnings. If you need further assistance, please let me know! =)

EDIT #3

But anyway, the StopLight quickstart […] seems to imply that the dependency mapping of interface to concrete class is done in code (which won’t work for me).

In fact, you can do both code and XML dependency mapping, the choice is yours! =)

Here are some example that you should perhaps inspire from to make the StopLight quickstart use the XML configuration instead of the coded mapping.

1. Testing Your Unity XML Configuration;
2. Using Design-Time Configuration;
3. Source Schema for the Unity Application Block.

If this doesn’t help you get through, let me know. I shall then provide a simple example using XML dependency mapping. =)