在我的公司（我最近加入），ASP.net解决方案用于为客户提供基于http的RESTful API。
事实上，这个“API层”层非常“薄”，有很多方法只包含2行代码：转换参数+调用更深层。
因此，“API层”将通过http调用获得的参数传递给下一层，后者将属性转换为“业务对象”，这些对象主要是仅具有属性的类，几乎没有逻辑。这个“业务层”再次将属性传递给“存储库层”，它填充了另一个类的属性（“参数类”），最终使用这些参数调用存储过程。
几乎所有“业务逻辑”都存储在存储过程中。
当他们被调用时，他们将out参数传递回C＃存储库层类并将其全部转换回“API Layer”。
简而言之：C＃类并没有真正使用任何逻辑或OOP。实际上，它们很可能是从存储过程参数自动创建的，因为这样简单：它们收集API参数，将它们传递给数据库（Oracle）到存储过程，并将存储过程调用的结果传递回API。
正如您对所描述的“架构”所期望的那样，目前还没有单元测试和集成测试。
所描述的体系结构相当陈旧，我想在80年代，在数据库中创建所有BL可能会有所帮助。
由于我已经习惯了TDD，我开始为现有的代码库创建单元测试，这很难，因为它不是为可测试性而设计的。不幸的是，除了使用“正确”参数调用“正确”存储过程之外，还没有太多要测试。
对于未来，计划通过存储过程访问数据库应该是唯一允许的方式，因此转移到某种O / R映射器可能是遥不可及的。
您如何看待这个“架构”？
它与我迄今为止在职业生涯中看到的任何（有用）代码都不相似。 （从版本1.0开始编程C＃，之前是C ++）
我习惯TDD，在C＃类中编写业务逻辑，使用OOP机制，SOLID代码，模式，......
数据库通常只是“持久层”，可以使用O / R映射器访问。
所以我不知道从哪里开始。您将如何开始，将这个80年代的“架构”转换为更多OOP风格？
我想应用现代的OOP编程风格来创建一个可维护的，可自动测试和自适应的解决方案，而不是继续将逻辑放在存储过程中，并使用C＃作为调用这些过程的包装器。
也许我可以创建一个使用Entity Framework通过调用存储过程来执行一些基本CRUD和查询操作的原型？
答案 0 :(得分：0)
感谢您的回复！ 我完全同意，只要需要付出努力，就必须将“商业价值”作为一种利益。
“大老稳定”应用程序的问题是需要新功能并且还不断添加（在存储过程中）但是很多代码已经很老了，没有人知道它真正做了什么。也没有人知道，如果添加新功能可能会破坏现有的“稳定应用程序”。
“稳定性”是必须具备的要求，不幸的是，在我看来无法保证，并且在添加功能而不添加任何测试时 - 事情甚至会进一步降级。
至少那是我的经验，而且我一直在一个项目中工作，而这个项目恰好与代码库有关。这些天来，我们没有进行测试，也不知道好的实践。事实上，经过3年的努力，我们不得不抛弃整个代码库并从头开始......是的，第二次我们首先了解了良好实践并以TDD方式进行了实践，代码库仍然具有足够的自适应性以增加新的需求，6年后。
所以我已经学会了“艰难的方式”，为什么一个可测试的和自适应的代码库很重要，我希望我和我的团队不必再这样做了。 ：）