Jam*_*low 11 c# vb.net migration ms-access
我目前正试图说服管理层需要将我们的一个应用程序移植到.NET.该应用程序已成为Access(SQL中的后端)中的一个怪物,具有700个链接表,650个表单/子表单,130个模块和850个查询.
我非常了解这样做的所有主要好处,但现在需要了解如何在技术上实现这一点,因此我可以将项目计划放在一起.
所以,我的计划是将查询转换为后端的存储过程和/或视图,并在WPF或WinForms中重写表单.
现在,代码是我解开的地方.是否有可能将代码打包并将模块打包到dll中并在将它们慢慢移植到VB/C#时使用它们？
我们不能留下的是VB/C#中的一半应用程序和Access中的一半应用程序,它必须"出现"所有应用程序,甚至是迁移的一半.
提前致谢.
编辑:更多关于我们做什么以及为什么我们正在考虑远离Access的信息.
我们本质上是一个ISV,Access应用程序是我们的主要产品.该应用程序已经开发了15年,由许多开发人员临时开发.此应用程序没有文档.
我们在SCC中使分支机构正常工作时也存在问题,因此我们目前为我们拥有的六个客户端提供了4或5个代码库.最重要的是,我们所做的所有测试都是完全手动的,您可以想象这是非常耗费人力的,而且只是划分了真正需要测试的内容.
我们目前正在寻求扩展,并且拥有一些处于最后阶段的销售线索.我担心,随着这些新的销售,我们将被支持和测试淹没,而且这个应用程序将变得更加纠结于一辆车.
我还要补充一点,即我们即将进入一个全新产品的规格阶段,这几乎肯定是用.NET构建的.如果我们要在.NET中重写Access应用程序,那么我们用于此的人可以直接进入这个新的开发.如果我们留在Access中,那么我们必须得到一些新的Access人员,一旦我们开始新的开发,他们将不得不接受再培训.
所以基本上它已经归结为两种选择,在Access中进行主要的重构工作以尝试并"更好地"组织代码,而那些建议剔除部件的人最有可能是正确的; 我确定有些部件不再使用.但是,我担心如果我们留在Access,我们仍然无法建立有效的测试,我们仍然没有适当的SCC分支,这将导致支持继续成为一场噩梦,以及任何未来的发展产品料更糟糕.无论哪种方式,我们即将开始进行大量工作,这要么是在Acces中完成的,要么是在.NET中完成的.
Alb*_*lal 11
我参与了许多迁移项目,其中一个正在从一个平台转换到另一个平台.我也看到了惊人的成本超支,并且估计这些类型的项目有多么困难.
在我创建的一些项目和平台中,我已经建造了大约25,000美元,更换此应用程序并重写它的成本导致其他团队接管该项目,结果成本超过750,000美元.
您还假设需要更换当前系统.您必须清楚地了解移动和替换当前平台和软件的实际目标是什么.简单地重写一些东西并将功能转移到另一个平台会产生很少的收益,除非花费很多钱,这对你们所有人的业务都没有好处(但是,如果他们说服你需要这样做)
你可能想要阅读Joel关于软件的这篇精彩文章(Joel的方式开发并创建了这个论坛堆栈溢出 - 我是他的一些论坛近10年的主持人),. 在这篇文章中,Joel警告并谨慎对待,只需重写完美的软件,不会生锈或磨损.
你不应该做的事情,第一部分
作者:Joel Spolsky
他们做到了.他们通过制造任何软件公司可以做出的最严重的战略错误来做到这一点:
他们决定从头开始重写代码.
文章:http://www.joelonsoftware.com/articles/fog0000000069.html
乔尔继续指出,在过去的10年里,那篇文章仍然是他最受欢迎的文章之一(并且有些争议)
采用一个运行良好的运行应用程序10年并完成其工作,然后简单地在另一个平台上重写它是没有意义的,特别是如果你没有Manpower,专业知识和人员来维护这个新的系统.如果新系统不会比以前的系统做得更多,那么尤其如此.事实上,如果你确实拥有Manpower,那么他们可能已经开始使用STARTED转换这个系统了.我的意思是为什么所有人突然突然发现有人扔了一个电灯开关,突然意识到需要引进新的开发人员来重写一个已经运行良好的系统？
我还要指出已经在这个行业工作了很长时间(访问书的出版和技术编辑)我还完成了从大型机系统到桌面的迁移项目.而且,我还完成了将桌面数据库系统迁移到大型主机系统的过程.
我只能说很少见到具有那么多表的应用程序.事实上,这个问题立刻引起了警钟.
由于这里有如此多的表,我不得不认为可能有很多进程,而且这里有多个应用程序拼凑在一起代表整个系统.如果不是这种情况,那么当然,除非你解决系统的非规范化特性,否则重写.net是没有意义的.数据已经在SQL服务器中的事实有所帮助,但这可能意味着您拥有马力,容量和基础设施来扩展设计不佳的东西并且首先
软件灵活性的一个主要部分来自于正确规范化的数据模型.您遇到的问题是您在SQL Server中拥有数据,并且将部分表单和功能重写为.net表单非常诱人,并继续使用当前现有的数据模型.不幸的是,这会让你陷入困境,因为你想继续使用现有的数据,并开始在.net中重写功能.然而,重写.net中的功能而不解决数据模型是一个非常糟糕的主意.
在具有讽刺意味的命运转折中,这是一个问题22,因为如果该系统具有非常出色的设计数据模型,您可能甚至不需要重新设计并将其转换为.net.Access和SQL Server可以轻松扩展到100个用户.并且,访问支持使用类对象,甚至源代码控制.
换句话说,请记住,人们可能会要求在.net中重写它,因为他们相信应用程序会神奇地增加灵活性,并且能够比他们不断变化的业务规则更快地进行更改.实际上通常会发生相反的情况,因为访问是一个非常RAD的工具.这意味着前线人员通常可以根据业务规则的变化进行修改,比IT部门及其开发人员团队更快地完成应用程序的下一个优秀版本.更糟糕的是,您不想让IT部门和那些数据模型不佳的开发人员陷入困境.
我的意思是,您是否现在聘请IT部门来构建每个电子表格并为人们提供优秀服务,因为当前的业务流程不够灵活？如果IT部门到处寻找每个人的桌子,握住他们的手,并为每个人正确构建excel表单,那将是非常好的,但在现实世界中它并不实用.因此,除了远离这些人之外,你也可以从他们身上取得优异成绩.
我只是指出我的蜘蛛意识告诉我,这里的数据模型将是一个真正的挑战.请记住,我总是会在相反的情况下使用糟糕的代码和精心设计的数据模型(伟大的代码,但可怕的数据模型).这样做的原因是数据设计很好,然后代码和应用程序实际上是自己编写的.通过优秀的数据模型,您可以轻松地针对不断变化的业务规则进行更改,这再次有利于优秀的数据设计而不是优秀的代码.当您拥有良好的数据模型时,您还可以加倍计算代码.因此,通过良好的数据模型,您可以将表单和功能以及UI移动到.net中,并且您可以无缝轻松地执行此操作,而现有的数据模型可以保留.
此外,转向这些新技术毫无意义,而且您将不再介绍为现有业务流程引入自助服务Web门户等内容的可能性.因此,今天我们现在可以允许客户操纵和使用当前锁定在系统中的一些信息.这可能很简单,因为他们检查订单状态而不是浪费宝贵的客户电话时间.或者它可能是一个简单的事情,比如加拿大的一家大型包装公司在实施其包裹跟踪系统的第一年如何节省了大约10,000,000美元.或者可能只是让客户查找其帐户余额这么简单.
所以现在在市场上,这些自助服务客户门户网站系统允许客户输入和使用并获取他们的信息,而不是调用组织内部的一些人员,然后他们转身并启动应用程序,然后操纵信息.客户在电话中.也可以让客户做这项工作!因此,从订单状态到欠款,银行业务或者现在的余额,今天真正的樱桃模型票是允许客户在单元服务门户网站上使用,该门户网站代表内部应用程序正在创建的所有有价值的信息.
如上所述,您必须要问,人力资源和人员将来建立和维护此应用程序的位置是什么？显然,现有的大量表格和表格的系统必须以某种方式创建,并代表了一些重要的时间和精力投入.您必须要问的关键概念是,那些来自构建现有应用程序的重要投资和资源在哪里？那么谁将维持新系统？换句话说,您需要设计新系统以降低维护成本.(我的软件的新版本可以为客户每年减少10或15小时的维护).
在一天结束时,良好的软件开发和良好的设计是良好的设计.如果系统现在满足您的业务需求,则使用Access或VB6或vb.net无关紧要.
我还应该指出,新版本的Access 2010可以创建.web表单.它们是XAML(zammel .net表格).我指出这一点,因为将前端皮肤从访问权限更改为.net会使您非常小,除非底层数据结构和设计也被修改以利用可以通过新技术实现的新的可能业务流程(例如那些单元服务门户网站).简单地用.net表格重新绘制字体结尾实际上非常浪费我的拙见,除非其他问题正在解决,例如数据模型,或某种类型的门户网站,这将提高灵活性.
你已经有了一些很好的建议.请记住,这实际上归结为这些人希望在.net中重写此软件的目标和原因.这些新的目标和愿望最好不要基于简单地将你现在拥有的表格改造成.net的借口,因为它将真正完成任何事情,并且不会提高他们解决他们当前系统不断变化的业务需求的能力使用显然一直在做过去.
祝你好运,我不认为这是一个可以在一个简单的论坛帖子中回答的问题,但至少你有很多可以在这里咀嚼,所以你可以得到滚动.
而不是告诉你它有多难 - 我相信你已经意识到 - 我会尝试抛出一些提示:
1)首先将您可以从MS Access中移除的所有内容移至MS SQL中.这意味着表,存储过程,视图等.如果您正确地执行此步骤,您的MS Access应用程序将成为真实数据库的前端,这已经是一个胜利.
2)在开始之前考虑放弃.可能更有意义的是识别哪些功能可以单独使用,而新功能可以获得WCF或MVC前端.
3)从VBA移植到VB.NET很有吸引力,理论上它更相似,但我不推荐这个.
我在部门工作,主要负责用.NET解决方案替换旧的Access应用程序.在我的公司中,Access应用程序用于简单场景,以满足单个员工或小组员工的业务需求.
有时Access应用程序增长,用户组增长或需要进行太多更改.在这种情况下,使用该Access应用程序的部门可以启动项目来重新创建应用程序.当这开始时,我们可以确定新应用程序将远离当前的Access应用程序.
首先,业务分析师被分配到项目中.他的职责是绘制当前的解决方案,并讨论当前解决方案的问题和对新解决方案的期望.我还没有看到"客户"只想更换当前解决方案的项目.每次客户还需要一些在Access中无法实现的新功能和扩展.
业务分析师创建了一些预期解决方案的初步描述,并将其传递给架构师.架构师决定将构建哪种类型的应用程序,需要什么类型的硬件基础架构以及应用程序如何连接到其他系统(如果需要).在此初始阶段之后,IT对应用程序和所需的更改有了全面的了解.这里进行了一些初步估算,以便计划项目并分配资源.这个估计是项目的边界.比我的团队开始做这项工作.
我们正在使用敏捷方法,因此我们的客户(内部团队)会逐步看到应用程序中的新功能.首先,我们收集一些用户故事的初始集(积压)(特殊要求形式),我们估计这些用户故事,并让客户优先考虑它们.我们选择用户故事的子集进行迭代(通常为2-4周).可以随时将新用户故事添加到待办事项中,但我们选择的用户故事在迭代期间无法更改.在迭代之后,我们呈现客户工作的软件部分.根据工作部分,客户可以决定更改积压的优先级或创建新的用户故事.我们重复这种方法,直到客户说停止或单位预算被消耗.重要的是,并非所有用户故事都必须完成.
从技术角度来看,除了少数差异之外,它与其他任何项目一样: