您如何看待首先为命令行开发？

您对首先开发命令行有什么看法,然后通过简单地调用命令行方法在事后添加GUI？

例如.

W:\ todo AddTask"与John会面,re:登录同行评审""John的办公室""2008-08-22""14:00"

加载todo.exe并调用一个调用的函数AddTask,该函数执行一些验证并在数据库中引发会议.

最后你在屏幕上添加:

============================================================

Event:    [meeting with John, re: login peer review]

Location: [John's office]  

Date:     [Fri. Aug. 22, 2008]  

Time:     [ 2:00 PM]

[Clear]  [Submit]

============================================================

单击"提交"时,它将调用相同的AddTask函数.

这是考虑到:

一种很好的编码方式

只是为了新手

可怕!

附录:

我注意到这里的趋势是"由GUI和CLI可执行文件调用的共享库".是否有一些令人信服的理由为什么它们必须分开,除了二进制文件本身的大小？

为什么不以不同的方式调用相同的可执行文件:

"todo /G" 当你想要全面的图形界面

"todo /I" 用于交互式提示内 todo.exe(脚本等)

"todo "当你只想做一件事并完成它时,你就会老去.

附录2:

有人提到"我[描述]的方式,每次GUI需要做某事时,你都需要产生一个可执行文件."

再次,这不是我的意图.当我提到示例GUI称为"相同的AddTask功能"时,我并不是说GUI每次都称为命令行程序.我同意这将是非常讨厌的.我曾打算(参见第一个附录)这一切都在一个可执行文件中,因为它只是一个很小的例子,但我不认为我的措辞必然会排除共享库.

另外,我要感谢你们所有人的意见.这是一种不断涌现在我心中的东西,我很欣赏你的经验.

我将使用链接到它的命令行应用程序构建库.然后,您可以创建链接到同一个库的GUI.从GUI调用命令行会为每个命令生成外部进程,并且会对操作系统造成更大的破坏.

此外,使用库,您可以轻松地对功能进行单元测试.

但即使您的功能代码与命令行解释器分开,您也可以重新使用GUI的源代码而不必同时执行两种操作.

将共享功能放在库中,然后为其编写命令行和GUI前端.这样,您的图层转换不依赖于命令行.

(此外,这种方式增加了另一个安全问题:GUI首先必须确保它是正在调用的正确的todo.exe吗？)

几年前,乔尔写了一篇文章,将这种("unix风格")开发与GUI首先("Windows风格")方法进行了对比.他称之为双文化主义.

我认为在Windows上将你的逻辑包装成.NET程序集将变得正常(如果它还没有),然后你可以从GUI和PowerShell提供程序访问它们.这样你就可以获得两全其美.

我首先编写后端功能的技术,而不需要显式的UI(特别是当UI不是我的工作时,例如,我正在设计一个仍在设计阶段的Web应用程序)是编写单元测试.

这样我甚至不需要编写一个控制台应用程序来模拟我的后端代码的输出 - 它都在测试中,并且与您的控制台应用程序不同,我不必抛弃测试的代码,因为它们仍然以后很有用.