在C#4.0中使用依赖项注入时处理异常

前端之家收集整理的这篇文章主要介绍了在C#4.0中使用依赖项注入时处理异常前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
首先,请原谅任何错字,因为英语不是我的母语.

假设我想在我的应用程序中使用构造函数注入.例如,我会有类似的东西:

public class FileDataProvider : IDataProvider
{
    public MyData GetData()
    {
        // Get data from a file
    }
}

public class DatabaseDataProvider : IDataProvider
{
    public MyData GetData()
    {
        // Get data from a database
    }
}

public class DataReader : IDataReader
{
    private IDataProvider dataProvider;

    public DataReader(IDataProvider dataProvider)
    {
        this.dataProvider = dataProvider;
    }

    public void OutputData()
    {
        MyData data = dataProvider.GetData();
        Console.WriteLine("{0}",data.ToString());
    }
}

如果我使用构造函数注入,我根据定义没有控制或想法实现IDataProvider的类的具体实例将注入到我的DataReader类中.这意味着在我的DataReader类中我不知道GetData方法中发生了什么,包括我不知道它是否可能抛出异常,如果是这样的事实是什么样的异常.

在我的OutputData方法中,我应该将我的代码包装到try {} catch {}块中,如果是这样,我应该捕获什么异常?如果我捕获IOException或sqlException或实际上任何类型的异常意味着我在某种程度上预先设定了IDataProvider可能/应该实现的方式.我认为这不好.我也可以注入一个XMLDataProvider或NetworkResourceDataProvider.但与此同时,我必须在某些时候处理异常.

我的问题:在一般情况下使用控制反转和构造函数注入更具体地处理异常和记录应用程序中发生的事情的正确方法是什么?另外,在实现接口的类中抛出异常的正确方法是什么(如果有的话)?

在我的问题中添加一个精度,我不会拥有将实现IDataProvider的代码,所以我甚至无法确定是否会引发自定义异常,例如DataProviderException.即使我为开发人员编写指导方针……

解决方法

在我看来,IDataProvider的具体实现应该捕获适当的异常(文件提供者的I / O,数据库提供者的sql),并引发另一个异常,它传达获取数据的一般错误,即DataProviderException.如果需要,您可以将原始异常存储为内部异常属性,以便不丢失信息.

这样做,DataReader使用者只需要处理这个特殊的异常,并且不受细节的影响.这假设消费者有办法处理异常,即重试是可能的.

猜你在找的C#相关文章