VBA中较大项目的缺点 [英] Disadvantages of bigger project in VBA
问题描述
我是公司的一个新项目，该公司具有基于Ms Access 97中基于Visual Basic for Applications(VBA)的更大的企业/会计系统.此应用程序仍然有效，它们进行了更新，并且一切工作都相对正常.但是他们希望将此应用程序提升到最高水平，加快开发速度，使该应用程序对最终用户更具吸引力，等等..但是我不怀疑继续使用此技术(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代码的最坏缺点是什么?
- 是否可以运行单元测试或任何类似技术?
非常感谢您的任何答复
Access接口现在几乎使用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?
我认为，更多 可能用于宏和简单功能 扩展了访问功能.
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).
但是，通常，访问哲学是一种以交互方式构建对象的方法，即单击并单击，然后仅在默认行为不足时才添加代码. 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屋！
