Question

我正在处理一个需要重组属于某个网站的项目的项目。它还在Web应用程序和引用的依赖项目之间具有紧密耦合的依赖关系。请帮助我提供一些关于如何将调用重新考虑到更易维护的代码的想法和工具。

主要方面是有各种功能消耗的促销活动（促销类有超过4种不同的方法可供使用），这些功能无法轻松排列。

请以最佳做法帮助我。

对不起家伙 - 由于限制，我无法分享太多代码，但希望以下帮助

我的项目使用N-Hibernate进行数据访问项目A- web项目 - 后面带代码的aspx和ascx 项目B-包含项目C（数据操作类）消耗的类定义项目C - 保存到数据库方法的业务逻辑（客户，订单，促销等）

问题在于项目C - 我不确定它是做了太多事情还是需要分解。但是还有很多其他子项目。

Project C支持基于参数将详细信息保存到DB 这里的一些类方法根据某些条件调用了促销，我想让事情更加健壮 - 下面的示例代码

项目-C 类 - OrderLogic

public void UpdateOrderItem(....)
{
....
....
...
}
Order order = itm.Order;
promoOrderSyncher.AddOrderItemToRawOrderAndRunPromosOnOrder(itm, ref order);
orderItemRepository.SaveOrUpdate(itm);

所以就像上面的类一样，促销是从其他地方调用的，我想简化这个调用促销类文件。所以我正在寻找一些概念。

Answer 1

在任何项目中最重要的，尤其是经常需要与持久层通信的Web项目，都是利用依赖注入。

但在此之前，您需要确保提供与数据库通信的服务的类都具有接口。通常，这些类称为数据访问对象（DAO）。所以，你有类似的东西：

public class UserDao : IUserDao
{
     public User GetUserById(int id)
     {
        ...
     }
}

根据经验，对于这些数据访问对象，如果它们包含条件逻辑，那么您应该将其重构为更加面向业务的服务（类）。您的数据库接口最好包含尽可能少的逻辑。它必须很薄，因为这个层很难进行单元测试，因为它依赖于数据库。

完成此操作后，使用依赖注入容器并注册IUserDao及其实现。

现在，继续前进，您将能够通过模拟UserDao实现来创建完全模拟该数据库的单元测试。

我可以建议：

Microsoft Unity for dependency injection
FakeItEasy用于单元测试模拟框架

其他好的：

Castle Windsor（DI）
Ninject（DI）
RhinoMocks（单元测试 - 嘲笑框架）

祝你好运！希望它有所帮助。

Answer 2

我强烈建议不要在不了解SOLID原则和依赖注入的情况下重新开始重构您的应用程序。我犯了这个错误，现在我的应用程序充满了服务定位器（反）模式实现，这些实现并没有让我的生活比以前更简单。

我建议您至少阅读以下书籍：

http://www.amazon.com/Agile-Principles-Patterns-Practices-C/dp/0131857258（针对SOLID原则）

http://www.manning.com/seemann/（用于.NET依赖注入）

http://www.amazon.com/Working-Effectively-Legacy-Michael-Feathers/dp/0131177052

可能的策略不仅仅是为了重构，而是考虑只重构比其他部分更多的部分。如果某些东西有效并且没有人会改变它，那么就没有必要重构它，这可能是一个时间的浪费。

祝你好运！

重组我的申请

2 个答案: