Соглашения об именах различны для всех, правильных ответов нет, есть только лучшие практики, но есть много неправильных. Когда дело доходит до объектно-ориентированного программирования, не стоит перегибать ради модульности некоторые вещи, например, проект DataHelpers, который будет использоваться в вашем бэкэнде, может быть чем-то, что вы носите с собой, но, скажем, класс помощника Gravatar (который является реальным классом в Microsoft.Web.Helpers) - это просто перебор, потому что String.Format() и метод хеширования md5 - это все, что вам нужно для этого. Это довольно много, что снова понадобится в другом проекте, когда дело доходит до модульности.
Это само собой разумеется, но убедитесь, что то, что вы называете ваши классы методов, имеет смысл в контексте вашей работы, при работе с asp.net MVC, что у меня будет проект CMS.Controller и проект CMS.View, но все будет в рамках решения CMS, где в классическом ASP.net я бы назвал CMS.BL или CMS.Web. Я бы не стал ничего размещать в AppCode, просто добавлял проекты в ваши решения и не называл их Common, когда при переносе кода между решениями они переполнялись пространствами имен * .Common.
Так что классифицируйте свои проекты с использованием кода с точки зрения того, для чего они используются, и обязательно реализуйте иерархию, чтобы ваш classX, который наследуется от Xbase, находился в той же иерархии в элементах проекта, когда вы реализуете этот тип шаблона. в ваших проектах вы добьетесь большего успеха, чем Xbase в CSM.Web.Core и classX в CMS.Web, который в дальнейшем проложит дорогу к циклическим ссылкам.
Вот пример проекта, над которым я работаю, он начался как приложение MVC, но позже превратился в проект с winforms и всем.
До тех пор, пока для вас есть смысл, и вам удобно, вы можете со всем справляться, как в приведенном ниже решении, у меня есть Data.Netsis.Entities, который наследуется от Entities.Netsis.
Надеюсь, это поможет.