Размещение интерфейсов в решении Visual Studio

Question

Что является наилучшей практикой в ​​отношении размещения Интерфейс типов.

Часто самое быстрое и простое, что можно сделать - это поместить интерфейс в тот же проект, что и его конкретные экземпляры, однако, если я правильно понимаю, это означает, что у вас больше шансов столкнуться с проблемами зависимости проекта. Является ли это справедливой оценкой ситуации, и если это так, это означает, что интерфейсы должны быть разделены на разные проекты?

Answer 1

Это зависит от того, что вы хотите сделать. Вы правы, что размещение интерфейсов и классов в одной сборке несколько ограничит полезность абстракции указанных интерфейсов. Например. если вы хотите загрузить типы в AppDomain с целью их повторной выгрузки, вы обычно получаете доступ к экземплярам через интерфейсы. Однако, если интерфейсы и классы находятся в одной сборке, вы не сможете загрузить интерфейсы без загрузки классов.

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

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

Answer 2

Это деталь развертывания. Есть несколько случаев, когда у есть для помещения типа интерфейса в его собственную сборку. Определенно при использовании их в разработке плагинов или любого другого вида кода, который выполняется в нескольких доменах приложений. Почти наверняка, когда Remoting или любой другой вид подключенной архитектуры.

Кроме того, это уже не так важно. Тип интерфейса похож на другой класс, вы можете добавить ссылку на сборку, если она вам нужна в другом проекте. Хранение их отдельно может помочь контролировать управление версиями. Рекомендуется хранить их отдельно, если изменение типа интерфейса может привести к широко распространенным изменениям в классах, которые их реализуют. Изменение [AssemblyVersion] при этом теперь помогает устранять проблемы развертывания, когда вы забыли обновить клиентскую сборку.

Answer 3

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

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

Затем снова есть упаковка;вы можете разрабатывать отдельные проекты и упаковать все в одну сборку при ее отправке.