安装和升级应用的高级设计
我需要编写一个非常简单的 WinForms 应用程序，但我经常陷入过度分析模式。 我陷入了“是”、“否”、“重试”循环，几乎没有考虑应用程序的操作，我开始考虑应用程序的“工作流程”。 我是否应该为每个任务都有一个方法，并在检查前一个任务没有引发“中止”标志后依次调用每个任务？
我是否应该实现一个简单的 ITask 接口和每个任务的类，然后循环遍历有序的任务集合？ 我应该用它作为 Windows 工作流的简单介绍吗？ 该应用程序及其任务集的范围肯定会增长，因此我对任务进行硬编码的第一个选择是最令人讨厌的，但考虑到应用程序的大小，只需更改代码即可轻松完成维护； 可执行文件始终与升级材料一起部署，而不是永久部署。
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.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
在工作流程基础上，我会将其保留在高级场景/项目中，您将在其中使用很多它，例如您希望根据用户/公司而变化的高度可定制的工作流程、复杂的工作流程需求、暂停/继续。
我会选择 ITask 路线，因为它的灵活性（相对于简单的方法），同时仍然简单。 我觉得它也会帮助您进行单元/集成测试。 也就是说，我建议密切关注任务的重用，例如文件移动任务，因为您不想以大量执行相同操作的任务结束。 只需在重构步骤中执行即可，这样您就可以让实际需求/使用决定您需要什么（在测试中 - TDD :)）。
On workflow foundation, I would keep it to advanced scenarios/projects, where you will use a lot of it, like highly customizable workflow that you want to vary per user/company, complex workflows needs, pause/continue.
I would go the ITask route for its flexibility (vs. simple methods), while still simple at the same time. I feel it will also help you with the unit/integration tests. That said I recommend to keep an eye on reuse of tasks, like say a file move task, as you don't want to end with tons of tasks that do the same. Just do it on the refactoring steps, so you let the actual needs/use dictate what you need (in tests - TDD :)).
做最简单的事。 您以后随时可以重构。
Do the simplest thing. You can always refactor later.
我将补充彼得的建议，“做最简单的事情可能会起作用这也是好的设计”。
有时，从设计的角度来看，“最简单”的事情也是最愚蠢的事情，并且它会在未来引起悲伤，这与极限编程的口号所追求的相反。
你的第二个选择对我来说听起来不错。 实现简单，设计好，方便后期维护。
I'm going to add to Peter's suggestion by saying, "Do the simplest thing could possibly work that is also good design".
There are times when the "simplest" thing is also the dumbest thing, from a design standpoint, and it will cause grief down the road, which is the opposite of what the Extremem Programming mantra is after.
Your second option sounds right to me. It is simple to implement, a good design and will facilitate maintenance later.