Exception handling, facade and singlet  
Author Message
Eder Andr&#233&#59;s





PostPosted: Visual C# Language, Exception handling, facade and singlet Top

Hello

I'm trayin to develop an application based on components using the model view control pattern. But a I need a hard comunication between each component. I heard that a can use the politics of exception handling, or the facade or singlet patterns. But I'm new on this. Can somebody help me



Visual C#5  
 
 
TaylorMichaelL





PostPosted: Visual C# Language, Exception handling, facade and singlet Top

(Stand on soapbox.) You should never use EH for any sort of control flow. Use EH only for handling exceptions and reacting to errors. (Step off soapbox.)

The MVC pattern can be implemented in any number of ways but most of the time it boils down to either a static class or a singleton pattern. In both cases you must allow the model and view to gain access to one or more controllers. Depending on the implementation you might have a single controller for all models or a separate controller for each type of model. The model would register itself with the controller as needed and send notifications through the controller. Views would use the controller to register for model notifications. Be aware that MVC is actually viewed as different things to different people. I've even heard recommendations about changing MVC to something else as it doesn't match the original pattern.

Assuming that you use a single controller for all models you could create a static controller class that allows models to register with it. Views can query the controller for available models and register for notifications. This is the simplest and fastest approach. However the static controller becomes a bottleneck for performance. It also has to manage any number of models which means it has to be pretty generic. This adds more work on the model and view side when working with the controller. For example in a truly generic controller it might have a single event that is raised whenever a model raises an event. The event would have to identify not only the model that raised the event but also the event ID and the event arguments (encoded in some format). This makes it hard to work with.

A limitation of the static controller is that you can have only one per application. If you throw in generics then you can create multiple static controllers (one for each type). But ultimately you are still limited. A workaround would be to create a custom static controller for each model type (i.e. a CarController for Car models and an AirplaneController for Airplane models). This gives you the ability to use a static controller for each model and allows you to create methods and events specific to the type. Working with such a controller is a lot easier. However now the view must know about the model type in advance. Furthermore if the view interacts with multiple models it also has to interact with multiple controllers. Finally note that derived model classes might want their own controller yet views might not be aware of that and continue to use the base class model.

In all this discussion I haven't mentioned singletons at all. In reality a singleton is nothing more than a single instance of a class. It is effectively static. Therefore the usage of a singleton class compared to a static class is almost identical. One advantage of singleton classes is that they can inherit from a base class which a singleton can not do. Therefore you'll need to decide the better route given your situation. Personally I use static classes when there is no fields in the class beyond any threading or initialization data. For classes that need to maintain information I use a singleton. For example my data access layer is static because beyond the connection string it manages no data. However the underlying data provider is a singleton because it manages a lot of data such as connection pool settings, security information, etc.

So, in summary, use a static class or singleton to implement the controller(s). Prefer a single controller for simplicity at the cost of usability. Use multiple controllers when the interactions are complex but define rules for handing base and derived models. IMHO.

BTW, this question is better suited for a language or design forum rather than the IDE forum. Please reserve the C# IDE for questions related to the C# IDE in VS. I'm moving your question to the C# language forum.

Michael Taylor - 12/15/06