Здравствуйте,
Допустим есть большая библиотека (.NET-сборка), в которой находится несколько сот разных классов, т.е. все навалено в кучу, там и бизнес-логика и DAL, и классы сущеостей предметной области и всякие хелперы.
Проект частный, т.е. это не какой-то там публичный фреймворк или библиотека.
Хочется этот клубок потихоньку грамотно поделить на отдельные библиотеки.
Сейчас пока не буду задавать конкретные вопросы и примеры проблем, а хочу спросить ссылки на материал по этой теме.
Я пока нашел только главу из книги Роберта Мартина "Agile Principles, Patterns, and Practices in C#", там как раз целая глава посвящена данной теме, есть интересные и полезные принципе разделения, но материала недостаточно, чтобы основательно разобраться в теме и потом с легкостью грамотно решать такие задачи в нетривиальных случаях.
В общем, посоветуйте что можно почитать.
Заранее спасибо.
Re: Материал по грамотному разделению классов в отдельные dl
Здравствуйте, MozgC, Вы писали:
MC>Хочется этот клубок потихоньку грамотно поделить на отдельные библиотеки.
С какой целью? Слишком много кода для одной сборки, хочется переиспользовать часть кода, или просто явно разделить приложение на слои и спрятать internal-члены для каждого слоя?
Если код уже разделён на слои, слои разнесены по неймспейсам — никакой проблемы вроде бы нет. Если этого ещё не сделано, и вам хочется узнать сам способ, как правильно разносить код — этого вам никто не скажет, единственно верного варианта нет.
Например, я предпочитаю разносить по отдельным сборкам костыли к фреймворку, бизнес-логику и UI, причём каждая сборка в списке не должна ссылаться на следующие.
MC>В общем, посоветуйте что можно почитать.
Задача из тех, что решается не по книжкам, а исключительно здравым смыслом. Я бы не надеялся найи что-то стоящее. Если чудо всё-таки случится — поделитесь найденным!
Re: Материал по грамотному разделению классов в отдельные dl
Здравствуйте, MozgC, Вы писали:
MC>но материала недостаточно, чтобы основательно разобраться в теме и потом с легкостью грамотно решать такие задачи в нетривиальных случаях.
Решите задачу так, как понимаете сейчас. Это даст опыт и понимание, в какую сторону копать. Легкость решения придет только после того, как вы n число раз эту задачу решите. Да и то, в нетривиальных случаях, наверное ее не будет. На то они и нетривиальные.
Здравствуйте, Sinix, Вы писали:
MC>>Хочется этот клубок потихоньку грамотно поделить на отдельные библиотеки. S>С какой целью? Слишком много кода для одной сборки, хочется переиспользовать часть кода, или просто явно разделить приложение на слои и спрятать internal-члены для каждого слоя?
Это хороший и правильный вопрос. Я хотел его обсудить в отдельной теме, и наверное ее создам, завтра
MC>>В общем, посоветуйте что можно почитать. S>Задача из тех, что решается не по книжкам, а исключительно здравым смыслом. Я бы не надеялся найи что-то стоящее. Если чудо всё-таки случится — поделитесь найденным!
Ну, как я уже писал выше, если вы еще не читали, то гляньте Robert Martin "Agile Principles, Patterns, and Practices in C#" Chapter 28 — Principles of Package and Component Design.
Re[3]: Материал по грамотному разделению классов в отдельные
Здравствуйте, MozgC, Вы писали:
MC>Ну, как я уже писал выше, если вы еще не читали, то гляньте Robert Martin "Agile Principles, Patterns, and Practices in C#" Chapter 28 — Principles of Package and Component Design.
Да пролистывал я её. Специально нашёл ещё раз — ничего существенного и практически полезного. В 28й главе всё то же "избегайте зависимостей между слоями, выделяйте переиспользуемый код, поменьше циклических зависимостей".
Тема слишком абстрактна, чтобы раздувать из ней практически-ориентированную дискуссию.
Re: Материал по грамотному разделению классов в отдельные dl
Для организации проектов существует более 9000 способов, но наиболее жизнеспособных среди них два ( на практике обычно приживается комбинированный из этих двух способов подход ):
1) Layer driven decomposition — что-то похожее на то, что вам рассказал выше Sinix, т.е. логика приложения разбивается на слои, каждый слой выделяется в отдельную сборку, следуя принципу наименьшей связности, т.е. чем меньше зависимостей от других слоев у него будет тем лучше. Выделяется сначала самый базовый слой ( обычно различные определения и контракты + Dependency container + ServiceLocator/ServiceProvider ), потом слой, который использует самый базовый слой ( обычно какая-нить бизнес-логика ) и т.д. по нарастающей пока не дойдете до самого высокого уровня ( обычно взаимодействие с пользователем или другой системой ). Еще раз, важно, чтобы каждый последующий слой был зависим только от предыдущего ( а лучше даже и от него не зависеть ) + самого базового слоев, доступ к остальным слоям только через ServiceLocator/ServiceProvider.
2) Feature driven decomposition. При таком подходе приложение делится на ядро ( обычно различные определения и контракты + Dependency container + ServiceLocator/ServiceProvider ), Оболочку ( UI ),
и законченный набор из фич, каждая из которых вынесена в отдельную сборку и не имеет прямых связей друг на друга, только на ядро и оболочку.
Еще раз повторюсь, в чистом виде в сложных приложениях вы не встретите ни одного из описанных выше подходов, только комбинации. Поэтому ваша задача скомбинировать из этого, то что нравится/подходит вам.
