Simple solutions are better in many cases. In fact, with experience comes feeling that flexibility is often overestimated. Sometimes this is hard to choose the best value of flexibily.
Here is one example of unnecessary flexibility.
In one of my projects there is some working algorythm running on server which is managed from client side. There are different ways to establish such a management:
1) Client sends new parameters to server and server immediately changes parameters that are in use.
2) Client changes data in DB (directly or through server). Then data is loaded by the server.
In the project I'm talking about I've chosen the latter. And I've decided to make immediate renewal of these parameters using some service that notify about the change in DB. In SQL Server there is Service Broker for this case which should be turned on to allow such a notification.
In the code (for C#) you can use SqlDependency class. Here are great tutorials for it:
SqlDependency example
Also, there are some limitations for it.
Limitations of SqlDependency
Usage of SqlDependency seems a little bit clumsy for me so I've found some open source wrapper (that was a good wrapper, but unfortunately I can't find the reference), changed it for my needs and used it in my project.
Well, the way described now doesn't seem to be the best way.
First of all, all of this seems to be overcomplification of the problem.
Second, if something changes in the DB, the notification comes immediately. When data is changed you should decide whether the data change should stop execution of algorithm or changes are such that you can replace some parameters on the fly.
Third, if client makes some substantial changes consequentially, every such change will affect the base and algorythm.
For my current experience, it's better to:
1) Not to use SqlDependency in such scenario (but this doesn't mean that this technique is not useful, there can be situations where it's necessary).
Here DB plays a role of proxy between client and server. It better to make some other type of connections between them.
2) Divide parameters of the algorythms into several groups:
Static parameters (settings) which are the most essential parameters of the algorythm.
Dynamic parameters which can be changed on the fly.
Optionally one can introduce also observable only parameters which cannot be changed be client.
3) Divide client application into two parts:
Settings part, where static parameters can be changed.
Management part, where dynamic parameters can be changed.
4) Introduce a "reset button" for a client to manually reload server if some settings are changed.
Here is one example of unnecessary flexibility.
In one of my projects there is some working algorythm running on server which is managed from client side. There are different ways to establish such a management:
1) Client sends new parameters to server and server immediately changes parameters that are in use.
2) Client changes data in DB (directly or through server). Then data is loaded by the server.
In the project I'm talking about I've chosen the latter. And I've decided to make immediate renewal of these parameters using some service that notify about the change in DB. In SQL Server there is Service Broker for this case which should be turned on to allow such a notification.
In the code (for C#) you can use SqlDependency class. Here are great tutorials for it:
SqlDependency example
Also, there are some limitations for it.
Limitations of SqlDependency
Usage of SqlDependency seems a little bit clumsy for me so I've found some open source wrapper (that was a good wrapper, but unfortunately I can't find the reference), changed it for my needs and used it in my project.
Well, the way described now doesn't seem to be the best way.
First of all, all of this seems to be overcomplification of the problem.
Second, if something changes in the DB, the notification comes immediately. When data is changed you should decide whether the data change should stop execution of algorithm or changes are such that you can replace some parameters on the fly.
Third, if client makes some substantial changes consequentially, every such change will affect the base and algorythm.
For my current experience, it's better to:
1) Not to use SqlDependency in such scenario (but this doesn't mean that this technique is not useful, there can be situations where it's necessary).
Here DB plays a role of proxy between client and server. It better to make some other type of connections between them.
2) Divide parameters of the algorythms into several groups:
Static parameters (settings) which are the most essential parameters of the algorythm.
Dynamic parameters which can be changed on the fly.
Optionally one can introduce also observable only parameters which cannot be changed be client.
3) Divide client application into two parts:
Settings part, where static parameters can be changed.
Management part, where dynamic parameters can be changed.
4) Introduce a "reset button" for a client to manually reload server if some settings are changed.
Комментариев нет:
Отправить комментарий