Дизайн оболочки C# для DLL с P/Invoke

Мне нужно мнение о написании управляемой (C#) оболочки для неуправляемой C++ DLL.

Допустим, у меня есть такой объект:

public class ManagedObject
{
  public void DoSomethingWithTheObject()
  {

  }
}

и предположим, что метод DoSomethingWithTheObject() должен вызвать неуправляемый метод DLL.

Теперь мне приходят в голову две приемлемые возможности:

public void DoSomethingWithTheObject()
{
    DllWrapperClass.DirectCallToUnmanagedMethod(some_value_type);
}

а также

public void DoSomethingWithTheObject()
{
    DllWrapperClass.MethodName(this);
}

В основном я спрашиваю, если

  1. класс-оболочка должен быть просто оболочкой для неуправляемых методов, и все объекты вызывают эти методы напрямую.

  2. класс-оболочка должен быть аккуратно интегрирован с объектами и максимально скрывать «неуправляемый способ» работы.

Я склоняюсь ко второму варианту, но хотелось бы услышать и другие мнения, так как у обоих способов есть свои плюсы и минусы.


person Darko Kenda    schedule 15.09.2010    source источник


Ответы (2)


Вариант 2. Это один из принципов, лежащих в основе самой .NET Framework: предоставить набор управляемых библиотек, которые согласованы независимо от формы неуправляемых API, которые они обертывают.

Ваша оболочка должна следовать Руководству по проектированию библиотеки классов .NET, насколько возможно. Вы поймете, что находитесь на правильном пути, когда ваша управляемая оболочка начнет ощущаться как чистый C#, а не слой над неуправляемой библиотекой DLL.

person Tim Robinson    schedule 15.09.2010
comment
Спасибо. У меня были точно такие же мысли. - person Darko Kenda; 16.09.2010

Как вы уже поняли, второй вариант всегда предпочтительнее, но теперь всегда возможен. Лучше абстрагировать неуправляемые или небезопасные части, но иногда клиентское приложение должно принимать решения или предоставлять много информации. В последнем случае вы закончите тем, что напишете много классов, которые только имитируют свои неуправляемые аналоги.

В общем, прячьтесь, как можете.

person Aliostad    schedule 15.09.2010