Соглашения об именах между уровнями программного обеспечения
Раньше я разделял соглашения об именах классов для каждого типа программного слоя, как вы и просили Однако в мире .NET, осознав, что каждый слой является его собственной сборкой, и сборки часто заменяются сборками, реализующими один и тот же интерфейс / интерфейсы, я обнаружил, что пространство имен является наиболее важным / эффективным изменением, и отбросил префиксы и суффиксы для конкретных классов, по большей части.
Например, раньше у меня были Customer (бизнес) и CustomerDAL (уровень доступа к данным)
.. и это часто менялось в моих недавних проектах на соответственно ...
Com.Example.ProjectName.Business.Customer и Com.Example.ProjectName.Data.Customer с интерфейсом ICustomer, используемым между ними вместо прямого доступа к какому-либо конкретному классу в целевом проекте.
Значение именования классов изменяется из-за низкой сплоченности
Обычно, реализуя суффикс или префикс класса , вы пытаетесь предотвратить конфликт имен между тесно связанными сборками .
Однако обычно рекомендуется иметь слабосвязанные сборки с помощью интерфейсов ; побочный эффект - вы больше не используете конкретное имя класса. В противном случае, используя тесно связанные сборки, вы также можете объединить их в одну сборку, поскольку они напрямую зависят друг от друга, а преимущество от отдельных сборок уменьшается.
Иногда мое программное обеспечение использует более описательный подход, например классы Customer и CustomerData , и я понимаю, что для этого используется суффикс, но целью является естественный поток, а не предотвращение конфликты имен, потому что мой интерфейс находится между ними независимо.
В двух словах, низкая сплоченность ставит вопрос о том, какие классы должны / могли бы быть названы в любом слое проекта относительно друг друга. И поскольку у вас уже есть отдельные сборки для бизнеса и ответственность за данные, вы должны безоговорочно хотеть присутствовать низкой сплоченности. Таким образом, мой ответ в контексте разработки приложения: без суффикса или префикса класса объективно лучше в соответствии с концепцией вопроса.
Пример кода C #
Ради полезного примера кода я включаю следующий скелет C #, чтобы показать политику именования классов, к которой я стремлюсь (или отсутствие политики может быть более точным).
Примечание. Этот пример в некоторых отношениях неполон, но демонстрирует концепцию того, как именование классов не имеет значения между сборками (даже если это одно и то же имя класса), поскольку они разделены с помощью интерфейсов.
Business.dll - сборка бизнес-уровня
Ссылка на сборку Shared.dll.
namespace Com.Examle.MyProject.Business {
using Com.Example.MyProject.Shared; // for ICustomer
class Customer {
// Reference obtained to an ICustomer implementation (not shown).
// Composition of the data customer, just for illustration purposes
ICustomer _cust;
// From business, a data access usage example:
public void GetData() {
_cust.SaveToDataSource();
}
}
}
Бизнес использует ICustomer вместо жесткого подключения к сборке Data.dll.
Shared.dll - Общая сборка - Общие типы ссылаются как на бизнес-сборки, так и на сборки данных.
// This is the only required link between business and data assemblies.
// Business is shielded from Data concrete class names and vice-versa.
namespace Com.Example.MyProject.Shared {
public interface ICustomer {
void SaveToDataSource();
}
}
Data.dll - Уровень доступа к данным
Ссылка на сборку Shared.dll.
namespace Com.Example.MyProject.Data {
using Com.Example.MyProject.Shared; // for ICustomer
class Customer : ICustomer { // implement ICustomer - other assemblies can too
public void SaveToDataSource() {
// logic to save data to the data source
}
}
}