Циклические ссылки в моих проектах C#
Я предпринял нерешительную попытку своего предыдущего задания при создании системы сборки (на основе GNU, делают), абсолютно нерекурсивный, но я столкнулся со многими проблемами:
- артефактам (т.е. библиотеки и созданные исполняемые файлы) распространяли их источники по многим каталогам, полагаясь vpath для нахождения их
- , Несколько исходных файлов с тем же именем существовали в различных каталогах
- , Несколько исходных файлов были совместно использованы артефактами, часто компилируемыми с различными флагами компилятора
- , Различные артефакты часто имели различные флаги компилятора, настройки оптимизации, и т.д.
, Одна функция GNU делает, который упрощает нерекурсивное использование, целевые значения переменных :
foo: FOO=banana
bar: FOO=orange
Это означает, что при создании целевого "нечто", $ (НЕЧТО) расширится до "банана", но при создании целевой "панели", $ (НЕЧТО) расширится до "оранжевого".
Одно ограничение этого - то, что не возможно иметь целевые определения VPATH, т.е. нет никакого способа исключительно определить VPATH индивидуально для каждой цели. Это было необходимо в нашем случае для нахождения корректных исходных файлов.
основная недостающая возможность GNU делает необходимыми для поддержки нерекурсивности, то, что этому недостает пространства имен . Целевые переменные могут ограниченным способом использоваться для "моделирования" пространств имен, но в чем Вы действительно нуждались бы, должен смочь включать Make-файл в подкаталог с помощью локального объема.
РЕДАКТИРОВАНИЕ: Другой очень полезный (и часто недогруженный) функция GNU делает в этом контексте, средства макрорасширения (см. оценка функция, например). Это очень полезно, когда у Вас есть несколько целей, которые имеют подобные правила/цели, но отличаются способами, которых нельзя выразить с помощью регулярного GNU, делают синтаксис.
4 ответа
Ваш проект Utility , ссылающийся на ваш MyCompany.MyProject.Domain , кажется немного запахом кода. Я предполагаю, что это утилиты, которые специально работают с объектами домена - в таком случае почему бы вам не включить MyCompany.MyProject.Utilities в свой проект Domain (естественно, соответствующим образом изменить пространство имен)?
В любом случае, нормальный способ разбить такие зависимости - это абстрагировать то, что требуется для одного проекта, в набор интерфейсов и инкапсулировать их в отдельной сборке. Однако перед этим убедитесь, что то, что вы делаете концептуально , является правильным.
Однако в вашей конкретной ситуации подумайте о внедрении интерфейса, а именно, INameHolder :
public interface INameHolder
{
string FirstName { get; set; }
string LastName { get; set; }
}
Затем Contact реализует INameHolder . INameHolder существует в другой сборке, назовем его MyCompany.MyProject.Domain.Interfaces .
Затем ссылки на ваш проект Utilities Интерфейсы (, а не Домен ), как и Домен , но Интерфейсы ни на что не ссылаются - циклическая ссылка нарушена.
скопируйте метод ToSlug в проект домена и вызов ToSlug служебной программы делегирования в этот новый метод
Если вы не можете совместно использовать домен (вероятно, правильно) и он должен использовать логику из общей библиотеки, тогда вам действительно нужно ввести другую сборку.
Или вы можете загрузить логику во время выполнения в домене путем отражения в домене для доступа к зависимой библиотеке. Это не сложно, просто нарушает проверку времени компиляции.
Если вы уверены, что храните код в служебной DLL (ответ Эрика мне кажется разумным), вы можете создать интерфейс в своем служебном проекте, передав этот интерфейс в качестве параметра в ваш метод ToSlug, а затем пусть ваш объект домена реализует интерфейс.