我是一个使用快速老化架构的大型企业web应用程序的开发人员,所以我们一直在讨论如何最好地实现应用程序的现代化。具体地说,它是一个MVC4.0Web表单应用程序,上面有一种ASP.Net,但它仍然使用所有的ascx。此外,我们正在使用一个名为Entity Spaces的数据库框架,它基本上已经让位于Entity Framework。我们正准备将应用程序迁移到.net 4.6,所以我们至少在运行一个现代版本,但我们希望有一天能够在应用程序上进行广泛的单元测试和测试自动化,而由于架构的原因,这目前是不可能的。
我的问题是,有没有人有任何好的信息或资源来最好地处理这个问题?例如,假设我们有一个ASP.Net 4.6Web应用程序,它下面有10个区域。是否有可能将一个区域拉出到它自己的项目中,并将其重构为使用Razor视图和实体框架,但仍然在同一个域中与其他尚未检修的区域一起运行?一口气重构整个应用程序永远不会卖给上层管理人员,但如果我们可以一次只重构一个模块(区域),那么它可能是可行的。任何有关技术可能性或我们可能面临的问题的信息都会非常有帮助。我无法想象其他大型企业应用程序不会遇到类似的问题,但我发现有关如何处理此问题的信息很少。
发布于 2017-12-14 03:09:21
如果您有一个包含所有业务操作的DLL,那么迁移到MVC问题的解决方案就可以得到解决;然后,您只需从Razor支持的MVC应用程序中使用它们,而不是从Web窗体应用程序中使用它们。
如果您在整个系统中都使用了DIP (依赖反转原则),那么迁移到EF的问题就可以得到解决;您只需将存储库/服务/dao的具体实现更改为EF适配器,而不是实体空间类。
编辑:但是,既然你问我们如何从我们现在所处的位置前进;
在迁移的微观层面上,我用一个中型的应用程序做到了这一点。我们已经使用了经典的DAO方法,然后我们想迁移到NHibernate。我们的DAO方法使用存储过程,所以我必须用NH的Linq to SQL方法编写所有的SP。我们在相当短的时间内处理了迁移,但我从来不确定我是否破坏了整个过程。非常幸运的是,我没有破坏所有的东西,并且在第一次尝试时它确实起作用了。但这纯粹是幸运的,如果我们有单元测试和集成ın测试,第一次就不会是幸运的,因为我们会在运行之前得到错误。
下面是我的迁移过程;首先,我设计了通用接口,因为我已经在前面编写了代码。我只需要从DAO中提取签名,并将它们放在单独的接口中。然后,我会将DAO的依赖项(主要是业务操作/服务)改为依赖于接口。然后,我将编写NHibernate具体类,并将它们作为具体实例提供给依赖系统。
所以,正如你所看到的,第一步是重新设计“界面”,这是从架构的角度重构系统的好机会。第二步是更改依赖关系。这是一个很好的机会来断言你在第一步中是否做错了什么。第三步是实施新系统。
https://stackoverflow.com/questions/47800276
复制相似问题