Дизайн пространства имен и осведомленность о классе

Question

Я помню, как однажды читал (я полагаю, что эта книга была Руководством по проектированию.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 и так далее.

Как будто существует негласное правило, которое гласит, что когда речь идет о пространствах имен: "Вы ничего не можете знать о своих собственных детях, но вы можете знать все, что нужно знать о детях ваших бабушек и дедушек, тетушек, дядей, племянниц", племянники и кузены ". Это руководство кажется мне нелогичным и бессмысленным; кажется, усложняет дизайн пространства имен.

Так вот вопрос

Как вы проектируете пространства имен в своих больших приложениях? Вы действительно заинтересованы в сохранении границ пространства имен? Если да, то как вы решаете проблемы, когда классы четко связаны (несмотря на то, что вы отстранены настолько, насколько можете)?

Мне действительно интересны ваш опыт и ваш вклад в это. Это беспокоило меня некоторое время. Если бы вы могли предоставить пример расположения пространства имен для трехуровневого приложения, которое включает в себя бизнес-объекты, объекты данных и т. Д., Было бы замечательно. Мне бы очень хотелось посмотреть, как вы, ребята, пришли к своим моделям пространства имен и почему.

Большое спасибо заранее!

Answer 1

Если у вас есть два тесно взаимосвязанных класса, вы просто помещаете их в одно пространство имен.

Я вижу пространства имен для хранения связанных классов, функций, перечислений и т. Д., Так что это должно быть вполне естественно.

Теперь может быть так, что некоторые пространства имен естественным образом основываются на элементах в других пространствах имен. Но если два класса так тесно связаны друг с другом, что я не знаю, почему я бы даже подумал о том, чтобы поместить их в разные пространства имен. Вероятно, есть веская причина, но я никогда не сталкивался с этим.