Я помню, как однажды читал (я полагаю, что книга была Руководством по проектированию .NET Framework), что, когда вы разрабатываете фреймворк или библиотеку классов, вы должны позаботиться о том, как вы расположите классы в своих пространствах имен. В частности, классы в родительских пространствах имен не должны знать о классах в дочерних пространствах имен. И наоборот, для классов в дочерних пространствах имен совершенно нормально знать о классах в пространствах имен над ними.
Например, классы в пространстве имен System ничего не знают о классах в пространстве имен System.Data.SqlClient . Однако классы в System.Data.SqlClient знают о классах в System и в System.Data .
Теперь, если принять за чистую монету, это довольно простая идея. Но бывают случаи, когда это не так легко реализовать, как вы думаете. Классы по своей природе связаны друг с другом. Например:
- бизнес-класс
- Класс сущности данных
- Класс, который отображает класс сущности данных в класс бизнес-объекта
- Классы, которые сериализуют объект данных в базу данных и из нее
Конечно, вы можете разделить их на отдельные, отдельные классы, которые четко изолируют данные и функциональность; это не моя проблема. Моя проблема заключается в том, как правильно расположить их в пространствах имен, которые соответствуют рекомендациям для пространств имен.
Это всегда казалось мне немного мутным. Я никогда не видел, чтобы это было четко адресовано, и большинство примеров, которые я видел, просто помещали объекты данных из корневого пространства имен (MyProject.DataObjects) или чего-то подобного. Как будто никто не уверен, поэтому мы просто не говорим об этом.
Я вижу, что в самой .NET Framework классы все время выходят за границы пространства имен, чтобы получить доступ к необходимой им функциональности. Классы часто получают доступ к функциональности из System.Collections , System.Collections.Generic , System.Runtime , System.Configuration , System.Reflection и т. Д.
Как будто существует негласное правило, которое гласит, что когда дело доходит до пространств имен: «Вы не можете ничего знать о своих собственных детях, но вы можете знать все, что нужно знать о детях ваших бабушек и дедушек, тети дяди, племянники, племянники и кузены ". Это руководство кажется мне нелогичным и бессмысленным; кажется, усложняет дизайн пространства имен.
Так вот вопрос
Как вы проектируете пространства имен в своих больших приложениях? Вы действительно все заинтересованы в сохранении границ пространства имен? Если да, то как вы решаете проблемы, когда классы четко связаны (несмотря на то, что вы были разделены настолько, насколько можете)?
Мне действительно интересны ваш опыт и ваш вклад в это. Это беспокоило меня некоторое время. Если бы вы могли привести пример расположения пространства имен для трехуровневого приложения, которое включает в себя бизнес-объекты, объекты данных и т. Д., Было бы замечательно. Мне бы очень хотелось узнать, как вы, ребята, пришли к своим моделям пространства имен и почему.
Заранее большое спасибо!