Question

我正在寻找关于在API中调用方法的代码层的架构的一些想法/意见。在我的例子中，调用代码是C＃/ .NET，API是非托管旧DLL的一部分。但同样的问题可能适用于许多不同的语言/环境。

我基本上是围绕非托管API编写托管包装器。包装器用于处理对非托管代码的封送处理，并将较低级别的错误和异常转换为托管异常。

经常出现以下模式，即API中的每个函数：

public void CallMethodX(<params>)
{
    try
    {
        API.MethodX(<params);
        <common code for checking for error conditions in API; convert to exceptions and throw>
        <common code for logging API call>
    {
    catch (SEHException xx)
    {
        <common code for querying API for more info on error and creating new managed exception>
    }
}

另请注意：各种API方法可以有不同的签名。

基本问题是：人们建议抽象出用于记录和错误处理的公共代码。即使在最好的情况下，即通过将公共代码移动到静态实用程序函数中，每个API方法调用都会有很多重复的样板代码。

我的一些想法包括：

将公共代码移动到实用程序类中，该实用程序类接受实际方法的委托并将委托注入实用程序类。然后，实用程序类执行实际的异常处理和日志记录。 [工作正常，但创建/传递委托有点笨拙/丑陋]。
使用命令模式。 [会很好地工作，但是为了共享代码似乎增加了很多复杂性]

还有其他想法吗？在哪里放置常见的异常处理代码的最佳OO实践？请注意，我不希望将处理程序代码放在调用堆栈的上方，即使用调用我的层的客户端找到它 - 因为该层应该与查询API的详细信息完全分离，以获取详细的错误信息并转换为托管异常

Answer 1

您可以看到的一个解决方案是Aspect Oriented Programing。这是AOP设计的问题类型。不幸的是，很多语言都不能很好地支持AOP，但如果你谷歌进行C＃面向方面编程，你会发现它是可行的Aspect Oriented Programming Using .Net

共享错误处理代码的设计模式

1 个答案: