Краще написати свою бібліотеку .NET, маючи на увазі обмеження COM, або відокремити свою .NET-бібліотеку від Interop?

Я натрапив на цю цікаву статтю: Як я полюбив сумісність COM у програмі CodeProject, яка змусила мене задуматися ...

Автор стверджує, що вони не хочуть ніяких COM-програм у своїй бібліотеці .NET, оскільки це відбирає красу їхньої бібліотеки .NET. Натомість вони б краще написати окрему бібліотеку Interop, яка виставляє їхню .NET-бібліотеку до COM. Ця бібліотека Interop поводиться з тим, що COM не підтримує конструкторів за допомогою параметрів, перевантажених методів, генеричних даних, спадкування, статичних методів тощо.

І хоча я думаю, що це дуже нове, чи це не просто завершує проект?

• Тепер вам потрібно протестувати свою бібліотеку .NET і бібліотеку Interop.
• Тепер вам потрібно витратити час на з'ясування того, як обійти вашу прекрасну бібліотеку .NET і виставити її на COM.
• Потрібно, фактично, подвоїти чи потроїти кількість своїх класів.

Я, безумовно, можу зрозуміти, чи потрібна вам ваша бібліотека для підтримки як COM, так і не COM. Однак якщо ви лише маєте намір використовувати COM, чи приносить такий дизайн дизайн якісь переваги, яких я не бачу? Чи отримуєте ви лише переваги мови C #?

Або це спрощує версію вашої бібліотеки, надаючи вам обгортку? Це робить ваші тестові одиниці роботи швидшими, не вимагаючи використання COM?

Однак якщо ви лише маєте намір використовувати COM, чи приносить такий дизайн дизайн якісь переваги, яких я не бачу?

Цей фрагмент коду вашого питання найбільш важлива частина вашого дизайнерського рішення тут, і відповідь (як завжди) , це залежить .

Якщо ви маєте намір використовувати бібліотеку лише через COM Interop, тоді вам слід створити всю систему, враховуючи це. Немає підстав для потрійного підрахунку рядків. Чим більше LoC в системі, тим більше дефектів у неї буде. Тому ви повинні розробити свою систему, щоб використовувати лише функціональні можливості, сумісні з COM.

Однак я не можу придумати вагомих причин обмежити використання бібліотеки .Net COM. Чому ви не хочете мати можливість використовувати збірку в іншому .Net-коді? Мало сенсу обмежувати себе таким чином.

У мене є певний досвід з цим, тому я поділюся тим, як я впорався з цим. Це, звичайно, не ідеально. Я зробив деякі компроміси. Я використовую лише фасад для COM-класів (інтерфейси дійсно), несумісні з новішими ідіомами .Net, інакше я безпосередньо піддаваю інтерфейс .Net COM. Це в основному означає, що я використовую фасад для будь-якого інтерфейсу, який використовує дженерики. Дженерики - це єдине, що я натрапив на це, просто просто несумісне. На жаль, це означає фасад для всього, що повертається IEnumerable<T>, що є досить поширеним явищем.

Однак це не так вже й погано, як здається, тому що ваш клас фасаду успадковується від вашого .Net класу та реалізує певний інтерфейс Interop. Щось на зразок цього.

namespace Company.Product.Feature
{
    public class MyClass : INetInterface 
    {
        // lots of code
    }
}

namespace Company.Product.Interop
{
    public class MyClass : Feature.MyClass, IComInterface
    {
        // over ride only the  incompatible properties/methods
    }
}

Це зводить ваш дублікат коду до абсолютного мінімуму і захищає ваш COM-інтерфейс від "ненавмисних" змін. По мірі зміни вашого основного класу / інтерфейсу, ваш клас адаптерів повинен переграти більше методів (або зламати інтерфейс і збільшити основний номер версії). З іншого боку, не весь ваш код Interop зберігається у Interopпросторі імен, що може призвести до заплутаної організації файлів. Як я вже казав, це торгівля.

Щоб отримати повний приклад цього, ви можете переглянути папки SourceControl та Interop мого репо. ISourceControlProviderі GitProviderстановитиме особливий інтерес.

це відбирає від краси їх бібліотеки .NET

Цьому автору потрібна ляска пробудження до обличчя. Мета будь-якого професійного проекту - зробити робоче програмне забезпечення, яке люди хочуть використовувати. Будь-які хибні ідеали щодо краси приходять довго після цього. Якщо це єдине їх міркування, автор втратив усякий авторитет.

Можливість позначити ваші заняття як видимі як кому-небудь та вміти спілкуватися з вашим кодом .NET через COM надзвичайно корисно. Відкидати цю велику користь для продуктивності для краси божевільно.

Однак, для того, щоб працювати з COM, потрібні деякі компроміси, вимагаючи конструктора без аргументів - це один із них, а деякі інші речі, які ви згадали. Якщо це ті функції, якими ви все одно не користуєтесь, або це не зашкодить вам не використовувати їх, то багато роботи потрібно зберегти, використовуючи той самий клас для COM і non com.

З іншого боку, якщо ваші COM-клієнти очікують різко іншого інтерфейсу, є залежності або інші обмеження, з якими неприємно боротися у ваших .NET-класах, або ви очікуєте, що вони істотно змінять ваші .NET-класи та потребуватимуть підтримання COM назад. сумісність, то будь-якими способами створити клас Interop для усунення цього розриву.

Але не думайте про "красу". Можливість викрити COM через .NET покликана заощадити вашу роботу. Не створюйте більше роботи для себе.

Ну, якщо чесно, то автор оригіналу цієї статті не використовував слова "краса" ніде в своїй статті, це ти, що може створити упереджене враження про це для тих, хто не встиг прочитати статтю себе.

Наскільки я зрозумів цю статтю, бібліотека .NET вже існувала і була написана без COM на увазі - ймовірно, тому, що під час створення бібліотеки не було потреби підтримувати COM.

Пізніше була введена додаткова вимога підтримки COM. Зіткнувшись із такою ситуацією, у вас є два варіанти:

• перепроектуйте оригінальну вкладку, щоб вона була сумісною з інтеропом COM (з ризиком зламати речі)

• дозвольте оригінальній робочій бібліотеці в основному такою, якою вона є, і замість цього створіть окрему збірку з функцією "обгортка" (або "адаптер")

Створення фантиків або адаптерів - це добре відома модель дизайну (або в цьому випадку більше архітектурна модель), а плюси і мінуси також добре відомі. Одним із аргументів для цього є кращий "розділення проблем", і це не має нічого спільного з красою.

До ваших проблем

Тепер вам потрібно протестувати свою бібліотеку .NET і бібліотеку Interop.

Коли ви впроваджуєте свій інтерфейс COM у існуючу бібліотеку .NET шляхом перепроектування, вам слід перевірити цей інтерфейс. Якщо представити адаптер, записаний вручну, можливо, знадобляться додаткові тести, що інтерфейс працює, але, звичайно, немає необхідності копіювати всі одиничні тести основної бізнес-функціональності. Не забувайте, що це просто ще один інтерфейс до ліб.

Тепер вам потрібно витратити час на з'ясування того, як обійти вашу прекрасну бібліотеку .NET і виставити її на COM.

Коли вам доведеться переробити оригінальну бібліотеку, ви також повинні це зрозуміти, і я думаю, це буде набагато більше роботи.

Потрібно, фактично, подвоїти чи потроїти кількість своїх класів.

Тільки для класів, які відкриваються через загальнодоступний інтерфейс COM, який повинен бути невеликою кількістю класів частиною вихідної бібліотеки.

Сказав, що для іншої ситуації, про яку ви згадали, коли ви вже знаєте, що вам потрібно підтримати COM як першокласного громадянина з самого початку, я вважаю, що ви правильні: вам слід врятувати клопоту щодо додавання окремої вкладки адаптера та розробити дизайн .NET lib з підтримкою COM безпосередньо.