views:

36

answers:

3

I'm working on a modular project consisting of multiple sensors, each inheriting from an abstract Sensor class. To configure each sensor, I have started to add a user control panel for each sensor (inherits from UserControl), which is loaded at runtime and displayed in a panel by the calling application.

But then I realised that to change sensor properties from the control, the Control class needs to have access to those properties or the sensor has to subscribe to configuration setting changes in the user control. This doesn't feel right, however, the control should be controlling the sensor.

What is the most elegant solution to control my sensors without creating a delegate-hell?

Should I continue on the path of:

class TestSensor : Sensor
{
    public UserControl ControlPanel { get; } // returns a TestSensorControl
    // ...
}

or should my sensors be created inside my controls:

class TestSensorControl : UserControl
{
    private TestSensor _sensor;
    public TestSensor Sensor {
        get {
            return _sensor;
        }
    }

    // ...
}

Sensors are responsible for checking for state changes and communicating it to the calling application by signalling an OnSensorEvent(...) event.

Alternatively, my base Sensor class could inherit from UserControl, and my SensorControl can inherit from that instead, eliminating the need for an intermediate control class.

A: 

You may have SensorController for each of your SensorControl and this SensorController should be responsible for updating the Sensor object. Each of the SensorControl will have its own Controller object which in turn update the model accordingly.

More it will lead to the MVC pattern.

saurabh
Note that this is not a web application and bears no relation to ASP.NET. Could you provide a code example of how to manage more than one sensor in this way?
FreshCode
MVC is not meant for WEB APPLICATION , you can have MVC in windows based application also.
saurabh
the problem is that microsoft then released an entire framework around it so now the term is conflated. the pattern MVC is still good though - however the asp.net mvc depends on the binding style of asp.net
John Nicholas
@John: I understand that MVC is a methodology, not the framework, but @saurabh's reference to SensorController seems like an ASP.NET MVC-ish way of doing it.
FreshCode
@FastCode: :) in MVC , you call the middle man a 'Controller'
saurabh
@FreshCode: If you want a Class Design of the above in terms of MVC , you need to update us your problem domain.
saurabh
+1  A: 

Id pass the sensor into control and have a subscription process.

John Nicholas
+1 Hmm, I considered this. But if my Sensor class passes itself to its control which is contained within itself, eg. SensorControl(this), it seems circular or redundant? Having the sensor inside the control means I don't have to add any more subscription methods.
FreshCode
i woul dnot have the control inside the sensor. I would have the control wrapping a sensor ... when you add a sensor to the control then the control can change the sensors values. If you want the sensor to be able to effect the control then i would use events. the control can then contain some decision logic and possibly adjust the sensor. I tend to code things like this against interfaces. Ie i would write an interface for the sensor.
John Nicholas
I don't want the sensor to affect the control, but I would like the control to subscribe to sensor events like the calling application.
FreshCode
oh ok in that case we are overcomplicating things. What you really have are a collection of controls and a collection of sensors. All you need to do is wire them up. These simply form collections of objects, the rest of your program then drives the thing. Ther is no need to have one of them as a proprty of another. Also consider that when an even is fired a reference to the object is also present ... ie it may not be necessary to have a 1:1 relationship in the number of sensors and controls.
John Nicholas
I might create a class/struct to hold both a sensor and a control that also wires them up and have some kind of a collection of these.
John Nicholas
Its a tricky decision without gettign the whole context. Essentially it may be simpler to manage by having the sensors as part of the cotnrol and using events to get the information to the control. However that doesn't model the situation which is what i was trying to do above. My first solutino is the easiest. However you clearly have some kind of looping code somewhere which can begin to favour the collection approach (as you are probably already iterating through a collecdtion of sensors).
John Nicholas
+1  A: 

It feels like you should keep your non-ui Sensor class which can be used by ui and non-ui controllers, and no need to create a base UserControl for every initialization of Sensor class.

I would suggest using inherited controllers(Sensors are created in Controllers). You can create a generic class SensorControl : UserControl ui and inherit from that class class TestSensorControl : SensorControl. That can save time and code dublicates.

You can define an abstract Sensor type in SensorControl and assign events in the constructor to be overridden.

Good luck

Ali YILDIRIM
Agreed, it's best to keep my non-ui sensor on its own so I can use it in other applications. On a side-note, since I'm using StructureMap for IoC, is there an elegant way of using IoC to provide (via a factory?) the correct type of UserControl depending on the type of sensor? Or is that better served by having each derived sensor return the correct type?
FreshCode
Yep ObjectFactory should work in this case. You can also add your SensorControl class a static function like: 'static SensorControl Create(Sensor s){}' and return the correct type of SensorControl based on Sensor in this func.
Ali YILDIRIM