AVK>Если есть объективные причины такого разнесения по сборкам (раздельная поставка, компоненты третьих фирм и т.п.) то вполне нормально.
Для разнесения на большое количество сборок есть и другие причины.
Главная из них это правильная декомпозиция и инкапсуляция для более крупных блоков кода чем класс. И пользование соответствующими фичами: internal types, раздельная компиляция, раздельные проекты в студии итд.
Можно конечно это все держать в уме и диаграммах, а код валить в кучу (разделив код на директории и неймспейсы), но это не то.
Для 30-50 тыс строк 10-15 раздельных проектов (и соответственно сборок) — это разве слишком много? Дык проблем будет гораздо больше если они не будут разделены.
Здравствуйте, Silver_s, Вы писали:
S_> Для разнесения на большое количество сборок есть и другие причины. S_>Главная из них это правильная декомпозиция и инкапсуляция для более крупных блоков кода чем класс. И пользование соответствующими фичами: internal types, раздельная компиляция, раздельные проекты в студии итд. S_> Можно конечно это все держать в уме и диаграммах, а код валить в кучу (разделив код на директории и неймспейсы), но это не то. S_> Для 30-50 тыс строк 10-15 раздельных проектов (и соответственно сборок) — это разве слишком много? Дык проблем будет гораздо больше если они не будут разделены.
Я тебе вот что скажу по опыту. В нашем проекте изначально был примерно такой подход. Когда количество проектов перевалило за 5 десяток, стало понятно что дальше так жить нельзя. В результате пришлось потратить довольно много усилий для склеивания проектов. Факторами, которые теперь влияют на разделение проектов, являются местоположение (сервер/клиент/дизайнер/утилиты/общее), конфигурация (у нас 2 варианта поставки), внешние компоненты, независимые универсальные фреймворки. В результате жить стало значительно легче.
Ни о чем — не говорит.
т.к. во-первых, программисткого словаря у них нет,
во-вторых, при разработке программ можно использовать, как прикладные аналогии — тогда справедливо использовать слово "компонент", так и математические аналогии, тогда справедливо слово "компонента".
Здравствуйте, AndrewVK, Вы писали:
AVK>Я тебе вот что скажу по опыту. В нашем проекте изначально был примерно такой подход. Когда количество проектов перевалило за 5 десяток, стало понятно что дальше так жить нельзя. В результате пришлось потратить довольно много усилий для склеивания проектов. Факторами, которые теперь влияют на разделение проектов, являются местоположение (сервер/клиент/дизайнер/утилиты/общее), конфигурация (у нас 2 варианта поставки), внешние компоненты, независимые универсальные фреймворки. В результате жить стало значительно легче.
И как это было интерпретировано? Как исправление ошибки, или как дальнейшее развитие.
Тут тоже не все так однозначно, есть приемущества при разбиении на большое количество компонет, есть и недостатки. На разных этапах проекта по разному. Эти все компоненты тоже ведь не одновременно появились. На некоторых этапах могут вобще существовать несколько вариантов определенных частей, с одной общей частью и необходимостью вносить изменения и в общую часть и в варианты. Здесь удобнее когда все разделено. Потом ближе к завершению реализации системы или подсистемы, удобнее уже объединять некторорые части.
VD>>Ну, и читай ее внимательно: VD>>
компонента, -ы (матем.) VD>>О чем по-твоему говорит выделенное?
Как вобще умудрились позаимствовать из английского слово component, и сделать из него два разных.
А их ведь еще как-то по всем падежам склонять как-то надо
Здравствуйте, Silver_s, Вы писали:
AVK>>Я тебе вот что скажу по опыту. В нашем проекте изначально был примерно такой подход. Когда количество проектов перевалило за 5 десяток, стало понятно что дальше так жить нельзя. В результате пришлось потратить довольно много усилий для склеивания проектов. Факторами, которые теперь влияют на разделение проектов, являются местоположение (сервер/клиент/дизайнер/утилиты/общее), конфигурация (у нас 2 варианта поставки), внешние компоненты, независимые универсальные фреймворки. В результате жить стало значительно легче.
S_>И как это было интерпретировано? Как исправление ошибки, или как дальнейшее развитие.
VD>>О чем по-твоему говорит выделенное?
DG>Ни о чем — не говорит. DG>т.к. во-первых, программисткого словаря у них нет, DG>во-вторых, при разработке программ можно использовать, как прикладные аналогии — тогда справедливо использовать слово "компонент", так и математические аналогии, тогда справедливо слово "компонента".
многократно используемый компонент (элемент программного обеспечения, который может использоваться множеством приложений и реализуется в виде dll- или ocx-файлов на основе стандартных интерфейсов)
Здравствуйте, Silver_s, Вы писали:
S_>Как вобще умудрились позаимствовать из английского слово component, и сделать из него два разных. S_>А их ведь еще как-то по всем падежам склонять как-то надо
Компонента (в единственном) используется как специальный математический термин, т.е. в очень специализированной области знаний. Компонет — это общеупотребительный термин используемый в том числе и в программировании.
Таких (перегруженных) слов в русском (да и в английском) море.
... << RSDN@Home 1.1.4 beta 3 rev. 207>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
S_> Для разнесения на большое количество сборок есть и другие причины.
Недавно в блогах какого то архитектора микрософта встретил упоминание о вредности дробления по мелким сборкам. Вкратце, очень большие затраты на подгрузку. Рекомендовали плодить как можно меньше сборок.
Здравствуйте, Andre, Вы писали:
S_>> Для разнесения на большое количество сборок есть и другие причины.
A>Недавно в блогах какого то архитектора микрософта встретил упоминание о вредности дробления по мелким сборкам. Вкратце, очень большие затраты на подгрузку. Рекомендовали плодить как можно меньше сборок.
А ведь и в самом деле! И как я на это раньше внимания не обратил! Тупо запускаем Task Manager и наблюдаем:
Каждое минимальное консольное .NET приложение, то есть каждый (консольный) компонент, отнимает 3.8 мегабайтов виртуальной памяти.
Каждое минимальное оконное .NET приложение, то есть каждый (оконный) компонент, отнимает около 8 мегабайтов виртуальной и 7 мегабайтов оперативной памяти.
Вывод: КОП в .NET еще очень переочень далека от совершенства. Представляю что было бы если бы в C# каждый файл исходного текста программы являлся бы модулем (как в Оберонах). По четыре метра на каждый минимальный модуль — это черезчур!
Теперь я понимаю почему у некоторых был сильный шок после того как я сказал, что если программа написана на нескольких сотнях файлах исходного текста, то и скомпилирована она должна быть в несколько сотен модулей. В Модулах и Оберонах 1 файл исходника = 1 модуль (компонент) системы. Разумеется, если в .NET такие огромные накладные расходы (от 4 до 8 метров минимум) на каждый модуль, то несколько сотен модулей мгновенно зажрут всю память! То есть, выходит, что .NET всего лишь деклалрирует, что она якобы компонентная, но на самом деле писать программы состоящие из сотен компонентов под .NET является безумством.
Для сравнения, запускаем BlackBox и идем в пункт меню Info -> Loaded Modules, видим список загруженных модулей. В моем блэкбоксе я насчитал 71 загруженный модуль (по умолчанию). Смотрю сколько он памяти занял: 7 мегабайтов оперативной 6 мегабайтов виртуальной. А если бы BlackBox был бы написан под .NET то семьдесят модулей заняли бы всю установленную на моем компе оперативку и дальнейшая работа была бы сильно усложнена.
Здравствуйте, Сергей Губанов, Вы писали: СГ>Вывод: КОП в .NET еще очень переочень далека от совершенства. Представляю что было бы если бы в C# каждый файл исходного текста программы являлся бы модулем (как в Оберонах). По четыре метра на каждый минимальный модуль — это черезчур!
Ты несешь абсолютную чушь. СГ>Теперь я понимаю почему у некоторых был сильный шок после того как я сказал, что если программа написана на нескольких сотнях файлах исходного текста, то и скомпилирована она должна быть в несколько сотен модулей. В Модулах и Оберонах 1 файл исходника = 1 модуль (компонент) системы. Разумеется, если в .NET такие огромные накладные расходы (от 4 до 8 метров минимум) на каждый модуль, то несколько сотен модулей мгновенно зажрут всю память!
А ты попробуй сделать минимальное консольное приложение, включив в него пару-тройку сборок. И расскажи нам, как зависит использование памяти от количества сборок. СГ>То есть, выходит, что .NET всего лишь деклалрирует, что она якобы компонентная, но на самом деле писать программы состоящие из сотен компонентов под .NET является безумством.
Неверное предположение конечно же приводит к неверным выводам.
... << RSDN@Home 1.1.4 beta 3 rev. 185>>
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
