Интерфейсы C# разделяют между различными проектами svn

Question

Я парень C++, который должен работать с некоторыми проектами C#, поэтому у меня есть вопрос. Имея два проекта, размещенных на разных серверах svn, мне нужно, чтобы они делились классами интерфейсов. Как это должно быть разрешено на C#.
Например, у меня есть файл CS, которые имеют интерфейс и класс, используемый для передачи данных в интерфейсе, т.е.

Public Class data 
{ 
    public int a; 
    public int b; 
} 
Public Interface Ifoo 
{ 
    int foo(data); 
} 

Этот интерфейс реализован в Projecta и используется ProjectB.
Я хочу, чтобы иметь возможность выбирать реализацию интерфейса, так что в тестах ProjectB я буду использовать специальную реализацию IFoo interface.Chosing различной библиотеки DLL с помощью:

Assembly assembly = Assembly.LoadFrom(asm_name); 
fooer = assembly.CreateInstance(class_name) as Ifoo; 

Где я должен поместить интерфейс IFoo?
Я думал, что он должен быть помещен в ProjectA svn repo (поскольку ProjectA является владельцем интерфейса), а затем проверить его как внешний с проверкой ProjectB.

Можете ли вы сказать мне, что такое эмпирическое правило?

BR
Кшиштофа

Answer 1

Прежде всего, что вы решили поставить свой интерфейс и asspciated класса данных (проект A или проект B SVN или новый), первый (и вполне ovious) Рекомендация для что вы объединяете их в свою библиотеку (DLL), без какой-либо зависимости от других объектов, чтобы стало проще делиться ею по разным проектам.

Чтобы использовать его в другом проекте (неважно, есть ли в другом хранилище svn или нет), вам придется предоставить этому проекту физический доступ к этому интерфейсу/классу данных. Будучи на собственной DLL и без ограничения необходимости требовать других объектов, просто добавить ссылку на библиотеку в проекте.

С локальными копиями обоих проектов вам не нужно копировать библиотеку непосредственно в другой проект.

В любом случае вам необходимо хорошо подумать о своем интерфейсе и данных, чтобы вы не делали никаких изменений в них, чтобы избежать проблем с совместимостью между проектами. Если вам нужно «добавить» что-то к интерфейсу из-за новых функций, вместо этого создайте новый интерфейс (и поместите его на другую DLL). Таким образом, вы будете поддерживать совместимость с другими проектами, которые не реализуют новые функции.

Если данные, связанные с интерфейсом, настолько конкретны, что любой класс, реализующий этот интерфейс, будет использоваться ТОЛЬКО по проекту A, поэтому очевидное место для размещения DLL в проекте A. Обычно это тот случай, когда программное обеспечение имеет возможность использовать плагины. Интерфейсы находятся в dll, которые могут быть «общедоступными» для разработчиков плагинов, которые не имеют доступа к самому основному проекту. Это настолько просто, что сделать DLL доступной для загрузки. Исходя из SAME, используемой как для основного проекта, так и для плагинов, проблем не будет (чем причина не изменять).

Но если ваш интерфейс более «общий» и используется для создания чего-то вроде рамки, где разные проекты (не связанные/не зависимые) могут использовать его в одиночку, чем предложение разделить его на третий проект (с его собственным svn) интереснее. Использование хорошей политики в отношении разработки этого интерфейса будет менее проблематичным для поддержки структуры.

В комментариях, которые вы сказали, вы можете связать «интерфейс» с проектом A, но если вы можете использовать его в проекте B без участия проекта A, вы также можете связать интерфейс с проектом B, предпочтительнее вариант перемещения интерфейса/связанных данных в проект по отдельности.

В любом случае реализация подчеркивания не имеет значения, поскольку основной причиной, по которой мы используем интерфейсы в C#, является то, что вы можете использовать объект «общим образом» без необходимости (обязательно) заботиться о том, реализованы.