这是一个假设的情景.假设您刚刚在一家拥有小型开发团队的公司工作过.该公司使用.NET 2.0编写的内部CRM/ERP类型系统来管理所有日常事务(让我们简化并说出客户帐户和记录).该应用程序是在几年前编写的,当时.NET 2.0刚刚推出并使用以下架构设计:
Web表单
数据层是围绕调用存储过程的SqlCommand的瘦包装器
通过sprocs填充的基本DTO样式的业务对象
一个"业务逻辑"层,充当webform和数据库之间的网关(即调用该层后面的代码)
让我们说,随着应用程序中添加了更多更改和要求,您开始觉得旧架构正在显示其年龄,并且变更越来越难以实现.您将如何引入重构步骤A)使应用程序现代化(即正确分离关注点)和B)确保应用程序能够轻松适应组织中的变化?
国际海事组织的变化将涉及:
将Linq等ORM引入Sql并删除CRUD的sprocs
假设您不能抛弃Webforms,请将MVP模式引入表单
确保网关类符合SRP和其他SOLID原则.
将重用的逻辑更改为Web服务方法,而不必重用代码
你的想法是什么?同样,这是一个完全假设的情景,我们许多人过去曾面临这种情况,或者可能最终面临.
你错过了我要经历的第一步:
成本效益分析
重构一个应用程序,因为你认为它感觉旧了并不是一个好理由.它仍然在运行(我在这一点上相当可靠地猜测)并且您的公司已经在代码中投入了大量时间和金钱.
你可能也有一个团队的开发人员所熟悉的.NET 2.0和Web窗体,而许多人可能不明白你在试图引进的概念/代码.
任何更改之前,弄清楚多少钱投资,你会多少钱,上进行更改用上了,它会多少钱,在未来节省...
如果数字没有加起来,那么任何业务都不会让你继续.