Решение.NET - много проектов по сравнению с одним проектом
Пока вращение данных на месте могло бы быть необходимым (возможно, для обновления физически сохраненного представления), это становится более простым и возможно более производительным для добавления слоя косвенности на доступ к массиву, возможно, интерфейс:
interface IReadableMatrix
{
int GetValue(int x, int y);
}
, Если Ваш Matrix уже реализации этот интерфейс, то это может быть повернуто через декоратор класс как это:
class RotatedMatrix : IReadableMatrix
{
private readonly IReadableMatrix _baseMatrix;
public RotatedMatrix(IReadableMatrix baseMatrix)
{
_baseMatrix = baseMatrix;
}
int GetValue(int x, int y)
{
// transpose x and y dimensions
return _baseMatrix(y, x);
}
}
Вращение +90/-90/180 градусы, зеркальное отражение горизонтально/вертикально и масштабирование может все быть достигнуто этим способом также.
Уровень должен был бы быть измерен в Вашем определенном сценарии. Однако O (n^2) операция был теперь заменен O (1) вызов. Это - виртуальный вызов метода, который является медленнее, чем прямой доступ к массиву, таким образом, это зависит от того, как часто повернутый массив используется после вращения. Если бы это используется однажды, то этот подход определенно победил бы. Если это повернуто тогда используемое в продолжительной системе в течение многих дней, то оперативное вращение могло бы работать лучше. Это также зависит, можно ли принять оплачиваемую авансом стоимость.
Как со всеми проблемами производительности, мерой, мерой, мерой!
10 ответов
По моему опыту, разделение кода, который создает единственный исполняемый файл в нескольких проектах, может быть полезно, если вы хотите
- использовать разные языки программирования. в различных частях
- разрабатывают библиотеки, которые также используются другими приложениями, или
- концептуально разделяют несколько уровней (то есть позволяют Visual Studio гарантировать, что нет прямых ссылок из проекта Lib на проект Приложение ).
Лично я основываю большинство своих решений на втором пункте. Считаю ли я, что эта часть приложения может быть более общей библиотекой, которая мне может понадобиться в другом приложении? Выложите это в отдельный проект. В противном случае, как вы указываете, наличие одного проекта обычно упрощает разработку.
О циклических зависимостях: Рекомендуемый способ решить эту проблему - поместить интерфейсы ссылочного материала в третий проект. Например, если у вас есть два приложения, которые совместно используют некоторые объекты посредством удаленного взаимодействия, вы помещаете интерфейсы общих объектов в проект библиотеки, чтобы гарантировать их доступность для обоих приложений.
Не зная точного дизайна вашего приложения, это сложно чтобы дать более конкретный совет.
Если у вас есть проекты с циклическими зависимостями, это указывает на проблему с дизайном кода, а не с моделью решения / проекта.
При создании зависимостей между проектами полезно всегда думать об одном как о «Нижнем», а о другом как о «Высшем»
Проект более высокого уровня (например, веб-интерфейс) должен зависят от более низких проектов. Более низкий проект (например, утилита) никогда не должен зависеть от чего-то более высокого, например веб-интерфейса. Если это произойдет, это означает, что в вашем проекте более высокого уровня есть что-то, что действительно должно быть в проекте более низкого уровня, или наоборот.
Мы заметили, что производительность Visual Studio значительно снижается по мере роста количества проектов. Такая простая вещь, как переключение с конфигурации «Отладка» на «Выпуск», может занять более 15 секунд для решений, содержащих около десятка проектов C #.
Кроме того, в качестве контраргумента к комментарию Рида о времени сборки: время сборки растет, потому что Visual Studio, похоже, тратит много времени на накладные расходы проекта. Фактическое время компиляции кажется быстрым, но общее время от запуска сборки до возможности запуска очень велико.
Я бы посоветовал свести количество проектов к минимуму, который вам может сойти с рук. Если вам нужно несколько проектов по уважительным причинам, используйте их по мере необходимости, но предпочитайте держать их вместе.
В общем, наличие нескольких проектов VS (в рамках решения VS) имеет смысл в этих случаях
- Вы потенциально может повторно использовать созданную DLL в другом проекте (библиотеке классов)
- Вы хотите разделить вещи, как в многоуровневой архитектуре, где вы можете удалить DAO dll и обмениваться ею с другой
- Существуют просто разные интерфейсные проекты (например, приложения ASP.net MVC), которые необходимо развернуть в разных физических местах, но использовать один и тот же BL, DAL.
Если вы говорите, что у вас проблема с циклическими зависимостями, то у вас проблема в вашем дизайн кода. Вероятно, вы можете поместить эту логику, которая используется в нескольких проектах, в библиотеку классов, предназначенную для повторного использования во многих проектах.
В общем, я бы сказал, что вы не должны ' t добавлять больше проектов, если они вам действительно не нужны. Разделение на проекты означает увеличение сложности, поэтому, когда вы это сделаете, вы должны получить от этого разумную выгоду.
Есть несколько причин для разделения решения на разные проекты (и, таким образом, сборки), и в основном это сводится к повторному использованию y и разделению ответственности .
Теперь ваша цель должна заключаться в том, чтобы сборка (также известная как проект) имела минимальное количество зависимостей от других сборок в вашем решении, в противном случае вы можете иметь все в меньшем количестве сборок. Если, например, ваши компоненты пользовательского интерфейса сильно зависят от вашего кода доступа к данным, то , вероятно, что-то не так.
На самом деле, это сводится к программированию с использованием общих интерфейсов.
Однако примечание:
Когда я говорю «в противном случае у вас может быть все в меньшем количестве сборок», я не обязательно предполагал, что это неправильный поступок. Чтобы добиться истинного разделения проблем, вам нужно будет писать намного больше кода и больше думать о своем дизайне. Вся эта дополнительная работа может быть не очень полезной для вас, поэтому хорошенько подумайте.
Вы можете найти следующую статью Мартина стоящей: Принципы проектирования и шаблоны проектирования (PDF) (Java) .
Пересмотренная версия на C #, в частности, доступна в Agile Principles, Patterns, and Practices in C # , также написанном Мартином.
Обе версии содержат разные рекомендации, которые помогут вам решить, что и где принадлежит. Однако, как уже отмечалось, циклические зависимости указывают на то, что либо есть проблемы с дизайном, либо что-то находится в компоненте, принадлежащем другому.
Несколько проектов позволяют лучше повторно использовать определенные типы в нескольких приложениях. Это также может сократить время сборки, так как некоторые проекты не нужно будет перестраивать для всех изменений кода.
Один проект облегчает жизнь, поскольку вам не нужно беспокоиться о зависимостях. Просто поймите, что простота имеет свою цену - она также позволяет упростить внедрение плохих проектных решений в кодовую базу. Циклические зависимости, будь то в одном проекте или в нескольких, обычно являются недостатком дизайна, а не требованием.
Там, где я работаю, мы выбрали подход, при котором цель состоит в том, чтобы иметь один проект для каждого решения. Все проекты библиотек кода также имеют приложение для тестирования и / или приложение для модульного тестирования.
Пока библиотеки кода проходят тестирование, версии выпуска (конечно, с файлом документации Xml) переносятся в папку «Live».
Любые проекты, требующие функциональности от этих других проектов, должны ссылаться на них из папки «Live».
Преимущества довольно очевидны. Любой проект всегда обращается к известному рабочему коду. Никогда не будет возможности сослаться на незавершенную сборку. Код тестируется для каждой сборки, что значительно упрощает понимание источника ошибки. Небольшими решениями легче управлять.
Надеюсь, это поможет!
Шад
Начать с одного проекта. Единственным преимуществом разделения вашей кодовой базы на большее количество проектов является простое сокращение времени сборки.
Когда у меня есть несколько многоразовых функций, которые я действительно хочу изолировать от основного проекта, я просто создаю для них новое решение.