VBA中更大项目的缺点 [英] Disadvantages of bigger project in VBA
问题描述
我是公司的新项目，该公司拥有基于 Visual Basic for Applications (VBA) 的更大的企业/会计系统，在 Ms Access 97 中.这个应用程序还活着，他们进行了更新，一切都比较好.但是他们希望将此应用程序提升到最高级别，加快开发速度，使该应用程序对最终用户更具吸引力"等等.但我不确定继续使用此技术 (VBA) 进行开发是否是个好主意因此我有几个问题.如果你能帮助我，我会很高兴.
i am new in project for company that have bigger enterprise/accounting system based on Visual Basic for Applications (VBA) in Ms Access 97. This application is still alive, they make updates and everything is working relatively fine. But they want to move this app to highest level, speed up development, make this app more "atractive" for end-users and so on.. But i'm not shure if it's good idea to continue developing using this technology (VBA) and therefore i have a few questions. I would be very glad if you could help me.
- VBA 甚至是为更大的项目而设计的吗?我认为，它更有可能用于宏和扩展 Access 功能的简单函数.
- 将应用程序转换为 .NET winforms/wpf 会更好
- 可以让更多的开发人员参与 VBA 项目吗?
- 与独立应用程序相比，在托管程序中运行的 VBA 代码的最大缺点是什么?
- 是否可以运行单元测试或任何类似技术?
非常感谢您的回复
现在访问接口几乎再次使用 SQL Server，但这并没有改变主要问题.
Access interface is now using almost agains SQL Server, but that doesn't change main problems.
推荐答案
这里没有来自任何拥有丰富 Access 经验的人的真正答案，所以我会给出我的答案:
There are no real answers here from anybody who demonstrates extensive experience with Access, so I'll give my answer:
1 VBA 甚至设计用于更大的项目?
1 Is VBA even designed for bigger projects?
定义更大的项目".一般来说，我会说不，但我在考虑企业范围的应用程序.但是这里的问题不是VBA能不能用，而是Access是否适合这种程度的应用的前端.Access 的最大缺点(除了表单部署问题)是管理项目，因为源代码控制不像其他开发平台那样容易.
Define "bigger projects." In general, I'd say no, but I'm thinking in terms of Enterprise-wide apps. But the question here is not whether VBA can be used, but whether Access is a front end appropriate for apps of this extent. The biggest drawback with Access (aside form deployment issues) is managing the project because source control is not as easy as with other development platforms.
但是您并没有真正了解应用程序有多大.它被数百人使用吗?或者它只有数百个子组件?也就是说，是复杂度大还是用户数量大?
But you don't really give an idea of how big the app is. Is it used by hundreds of people? Or does it just have hundreds of sub-components? That is, is it big in terms of complexity or big in terms of number of users?
我认为，它更多可能用于宏和简单的函数扩展了 Access 功能.
I think, that its more likely for macros and simply functions which extends Access funcionability.
正如我所说，你问错了问题.问题是 Access 是否是合适的前端.如果是，那么 VBA 就是您必须使用的语言.
As I said, you're asking the wrong question. The issue is whether Access is an appropriate front end. If it is, then VBA is the language you have to write it in.
关于宏和简单函数"的术语有问题，Word和Excel的宏"是在VBA中生成的，这让很多人认为VBA是一种简单的语言.VBA 实际上是 VB6 的一个 SUPERSET(不是子集)——VBA 具有比 VB6 本身更多的内置功能.使用 Access，大部分功能都特定于与数据库的交互，因此非常有用(例如，将 Access 绑定表单与 VB 表单进行比较).
As to "macros and simple functions" there's a terminological problem in that Word and Excel "macros" are generated in VBA, which makes many people think that VBA is a simple language. VBA is, in fact a SUPERSET of VB6 (not a subset) -- VBA has MORE functionality built in than VB6 itself. With Access, most of that functionality is specific to interacting with databases, and because of that is very useful (compare an Access bound form to a VB form, for instance).
不过，一般而言，Access 的理念是，您首先以交互方式、点击方式构建对象，然后仅在默认行为不够用时才添加代码.VBA 提供了很大的灵活性，因为它可以与任何具有 COM 接口的工具进行交互.它可以做的事情基本上是无限的(尽管实用性肯定是有限的).
In general, though, the Access philosophy is one in which you begin with building objects interactively, point-and-click, and then add code only when the default behaviors are not sufficient. VBA allows a great deal of flexibility in that it can interact with any tools that have a COM interface. It's basically unlimited in what it can do (though certainly there is a limit to what is practical).
2 将应用程序转换为 .NET winforms/wpf 会更好
2 Will be better to convert the application to .NET winforms/wpf
更好"的目的是什么?如果您有一个可以工作的应用程序，您真的必须考虑 Spolsky/Netscape 效果(上面引用过).当然，您可能会获得更好的代码管理，但代价是必须维护更多代码.另一方面，如果您在该开发平台上拥有内部专业知识，而没有 VBA 方面的专业知识，那么您就会倾向于迁移到更适合您的特定开发人员的开发平台.
"Better" for what purposes? If you have a working application, you really have to consider the Spolsky/Netscape effect (cited above). Certainly you might get better code management, but at the cost of having to maintain a lot more of it. On the other hand, if you have inhouse expertise on that development platform and none with VBA, then there's going to be a bias towards migrating to the development platform that's more suited to your particular developers.
但这并不是真正的更好"问题，如果不了解所有问题和涉及的人员，就无法真正确定.
But it's not really an issue of "better," which can't really be determined without knowing all the issues and personnel involved.
3 可以在 VBA 项目上工作更多的开发人员吗?
3 Can work more developers on VBA project?
使用 Visual SourceSafe，您可以让多个开发人员处理该项目.或者，您可以使用 Application.SaveAsText/.LoadFromText 自动构建并使用您选择的 CVS.
With Visual SourceSafe you can have multiple developers working on the project. Or, you could automate your build using Application.SaveAsText/.LoadFromText and use the CVS of your choice.
但总的来说，我认为 Access 更适合单开发者模型.
But in general, I'd say that Access is much better suited to a single-developer model.
4 在宿主程序中运行的 VBA 代码的最大缺点是什么反对独立应用程序?
4 What are the worst disadvantages of VBA code running in hosting program against stand-alone application?
我不知道这个问题是什么意思.许多人有一个疯狂的想法，即 Access 前端的工作集比做同样事情的 VB6 应用程序的工作集大，但实际上并非如此.我希望 .NET 大致相同(如果不是更大的工作集，因为随着进步"的推进，事情总是变得越来越大).
I have no idea of what this question means. Many people have the crazy idea that the workset for an Access front end is bigger than the workset for a VB6 app doing the same thing, but it's actually not true. I would expect .NET is about the same (if not an even bigger workset, since things always get bigger and bigger as "progress" marches forward).
在我看来，Access 的最大缺点是部署问题，任何需要多个 Access 版本的用户都会遇到很多问题.SageKey 安装脚本旨在解决该问题，但它们是临时性的——它们会在出现问题时进行修复，因此如果您的部署环境存在尚未遇到和处理的问题，那么您就没有运气.但它们确实涵盖了大多数此类情况.
The biggest disadvantage of Access, in my opionion, is the problem of deployment, where any users who need multiple versions of Access can have lots of problems. The SageKey install scripts are designed to fix that, but they are kind of ad hoc -- they fix problems when they come up, so if you have a deployment environment with problems they haven't yet encountered and handled, you're out of luck. But they do cover most such circumstnaces.
5 是否可以运行单元测试或任何类似技术?
5 Is possible to run unit tests or any similar technology?
我不这么认为，但是作为一名 Access 开发人员，我可能不太清楚单元测试到底是什么.Access 应用程序的大部分代码是用户界面而不是算法编程，所以我认为它不容易测试.这是否是一个问题取决于项目的性质和认为必要的测试类型.
I don't believe so, but then, as an Access developer, I probably don't have any really good idea what unit testing really is. Most of an Access application's code is user interface not algorithmic programming, so it's NOT going to be easily testable, I'd think. Whether this is an issue or not depends on the nature of the project and the type of testing that is believed to be necessary.
对于会计应用程序，您确实需要高度的可靠性，正如我在别处的评论中所说的那样，如果有人采访我的潜在项目来构建会计应用程序，我建议他们不要从从头开始，无论选择哪个平台.
For an accounting app, you really do require a high level of reliability, and as I said in a comment elsewhere, if somebody interviewed me for a potential project to build an accounting app, I'd recommend they not build it from scratch, regardless of the chosen platform.
这篇关于VBA中更大项目的缺点的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
