Лучший подход для создания библиотек C# для разных выпусков программного обеспечения?

Question

Мне нужно создать три разных выпуска DLL, содержащих вызовы API нашего программного обеспечения. Я до сих пор понял, как это сделать, используя наследование. Может кто-то, пожалуйста, подтвердите, правильно ли я использую наследование (или если у вас есть предложение сделать это правильным/лучшим способом?) Я новичок в этом, так что все еще изучаю программирование на C#.

До сих пор у меня есть основной класс API_calls (которые являются общими для всех DLL изданий) следующим образом:

namespace APIcalls 
{ 
    public partial class API_Calls 
    { 
    public void Common_function1() 
    { 
    } 

    public void Common_function2() 
    { 
    } 
    } 
} 

Тогда у меня есть три .cs файлов класс с чем-то вроде следующей в каждом из них (Edition_A , Edition_B и Edition_C являются различными факторами для каждого издания DLL), любые дополнительные вызовы включены в API_Calls частичных классов следующим образом:

namespace dll_edition 
{ 
public class Edition_A 
{ 
    public Edition_A() 
    { 
     // Code here for checking if current DLL is authorized 
     // Otherwise throw an exception 
    } 
} 
} 

namespace APIcalls 
{ 
    public partial class API_Calls : Edition_A 
    { 
    public void Additional_Edition_A_function1() 
    { 
    } 

    public void Additional_Edition_A_function2() 
    { 
    } 
    } 
} 

в каждой сборке билде я включаю Edition_A файл, или Edition_B или Edition_C, а затем я создаю все три сборки, которые дают мне три библиотеки DLL.

Мой вопрос: Это правильный способ сделать это? Есть ли какие-то негативные отзывы о том, как я это сделал? Или есть лучший способ сделать это? Моя конечная цель - иметь три версии DLL с некоторыми общими вызовами API в них, а затем различные вызовы API, характерные для каждого типа DLL.

Благодарим за любой вклад, который у вас может быть!

-DD

Answer 1

Из того, что я понимаю, вы набор общих функций в общем базовом классе, который будет использоваться различными другими классами.

Существуют различные способы сделать это своими плюсами и минусами: -

1) Создание раздельные библиотеки для каждого типа, которые вы делаете, в котором только ограниченная функциональность идет к конечному пользователю и размер DLL является small.This лучше подходит, если у вас есть dll, работающие над плюсом и игрой, где вы просто сбрасываете dll в bin, и новая функциональность на месте.

Это также делает ваши изменения центрическими, поэтому вы знаете, где ваши изменения. Но что, если вы распространили DLL на конечных клиентов и им нужен метод в другой DLL, вам снова придется переиздавать ваши изменения.

2) Выполнение всего этого в 1 dll, нежелательная функциональность подвергается воздействию клиента, пакет развертывания может быть тяжелым. Но у вас есть все возможности, которые легко доступны.

Подведение итогов будет в основном зависеть от вашей модели бизнеса и развертывания.

Answer 2

Лично я являюсь большим поклонником выполнения всего этого в одной DLL и используя Factory Pattern, чтобы определить, какая версия запускается во время выполнения, но если она должна быть 3 в соответствии с вашими требованиями, вот что я рекомендую.

Создать 4 библиотеки DLL.

Первый проект будет содержать интерфейс редакции (например, структура библиотеки DLL, но не содержит информации о том, как она будет работать). Этот интерфейс может быть присоединен к классам для разных версий DLL. С помощью этой структуры будет настроен код вызова, чтобы он мог использовать инъекции зависимостей для разных выпусков DLL.

Другие 3 библиотеки DLL будут представлять собой разные версии DLL, которые требуются для сборки.