High Level Design for Installation and Upgrade Application
-
I need to write a very simple WinForms application, but I often get stuck in over analytical mode with these. I get stuck on Yes, No, Retry loops, and with very little thinking to do about the actions of the application, I start thinking about the 'workflow' of the application. Should I just have a method for each task, and call each one sequentially, after checking that the previous didn't raise an 'abort' flag? Should I implement a simple ITask interface, and a class for each task, then loop through an ordered collection of tasks? Should I use this as a simple introduction to Windows Workflow? The scope of this application and its set of tasks is guaranteed to grow, so my first option of hard coding the tasks is the nastiest, but given the size of the app, maintenance can quite easily be done by just changing the code; the executable is always deployed with the upgrade materials, and not permanently deployed.
-
I need to write a very simple WinForms application, but I often get stuck in over analytical mode with these. I get stuck on Yes, No, Retry loops, and with very little thinking to do about the actions of the application, I start thinking about the 'workflow' of the application. Should I just have a method for each task, and call each one sequentially, after checking that the previous didn't raise an 'abort' flag? Should I implement a simple ITask interface, and a class for each task, then loop through an ordered collection of tasks? Should I use this as a simple introduction to Windows Workflow? The scope of this application and its set of tasks is guaranteed to grow, so my first option of hard coding the tasks is the nastiest, but given the size of the app, maintenance can quite easily be done by just changing the code; the executable is always deployed with the upgrade materials, and not permanently deployed.
I found it hard to find an answerable question. What did strike me was your statement "...guaranteed to grow/hard coding the tasks is the nastiest" followed by "given the size of the app, maintenance can quite easily be done by just changing the code". You seem to have a bit of a conflict.
-
I found it hard to find an answerable question. What did strike me was your statement "...guaranteed to grow/hard coding the tasks is the nastiest" followed by "given the size of the app, maintenance can quite easily be done by just changing the code". You seem to have a bit of a conflict.
I think my sentences ending with question marks are quite easy to answer, even if those without are hard to comment on. :) OK, hard coding the tasks is still the nastiest, but the cost of doing this is quite low, so I will be getting into a conflict with management if I can't produce a configurable application in the same time as I can produce a hard-coded one. We're never going to reach even fifty tasks, and if no code is reproduced between tasks, maintaining the hard coded task is feasible enough for the powers that be to sanction a hard-coded app. I, however, do not feel nice about hard coding the app.
-
I think my sentences ending with question marks are quite easy to answer, even if those without are hard to comment on. :) OK, hard coding the tasks is still the nastiest, but the cost of doing this is quite low, so I will be getting into a conflict with management if I can't produce a configurable application in the same time as I can produce a hard-coded one. We're never going to reach even fifty tasks, and if no code is reproduced between tasks, maintaining the hard coded task is feasible enough for the powers that be to sanction a hard-coded app. I, however, do not feel nice about hard coding the app.
I did have a look at your questions, for example your question: "Should I just have a method for each task, and call each one sequentially, after checking that the previous didn't raise an 'abort' flag?" My answer came to: Possibly, if that what the User wants; which seemed a bit superflous. Anyway I see you mentioned Windows Workflow. I've never used this but had a look at one of the Intro articles on CP. Workflow looks like it will separate the logic of the task from the details of performing the actions which I'd definitly agree is good. Having worked both as a software developer and as a manager of s/w developers, what really got to me was developers investing so much time/effort in designing and producing a framework in which to execute tasks (with task interface etc) that the framework became their goal, but as no one else knew the details of this framework it tied, and delayed, the project into using it. If Worlkflow gives you that framework - which it seems to, I'd use that to develop/code your actions/tasks first and do yout own framework later if its needed. But don't let your management think that the Workflow front-end you may show them is the finished thing if its not. They may assume its a completed front-end. It looks as if playing with Yes/No/Abort etc is relatively easy in the Workflow and separates from you task objects.
-
I did have a look at your questions, for example your question: "Should I just have a method for each task, and call each one sequentially, after checking that the previous didn't raise an 'abort' flag?" My answer came to: Possibly, if that what the User wants; which seemed a bit superflous. Anyway I see you mentioned Windows Workflow. I've never used this but had a look at one of the Intro articles on CP. Workflow looks like it will separate the logic of the task from the details of performing the actions which I'd definitly agree is good. Having worked both as a software developer and as a manager of s/w developers, what really got to me was developers investing so much time/effort in designing and producing a framework in which to execute tasks (with task interface etc) that the framework became their goal, but as no one else knew the details of this framework it tied, and delayed, the project into using it. If Worlkflow gives you that framework - which it seems to, I'd use that to develop/code your actions/tasks first and do yout own framework later if its needed. But don't let your management think that the Workflow front-end you may show them is the finished thing if its not. They may assume its a completed front-end. It looks as if playing with Yes/No/Abort etc is relatively easy in the Workflow and separates from you task objects.
Jonathan Davies wrote:
Possibly, if that what the User wants; which seemed a bit superflous.
This is to a dictatorial application, i.e. it forces the user to do what the project owner, our management, wants. This is a utility to upgrade our main application, and the only user option is the required main application path. 'User' requirements are moot after the task of getting that location.
Jonathan Davies wrote:
Having worked both as a software developer and as a manager of s/w developers, what really got to me was developers investing so much time/effort in designing and producing a framework in which to execute tasks (with task interface etc) that the framework became their goa
:-O Sounds like me sometimes. I used to be worse though. Thanks for your input. :rose: