Именование классов бизнес - логики

Question

У меня есть бизнес-уровень, в котором есть некоторые бизнес-объекты / POCOs / entities / что угодно.У меня также есть несколько репозиториев для доступа к данным.Вплоть до этого момента я получал доступ к репозиториям непосредственно с моего уровня пользовательского интерфейса.Я нахожусь на том этапе, когда мне действительно нужны еще несколько классов, которые не являются прямым CRUD, поэтому я собираюсь создать несколько классов бизнес-логики, которые будут выполнять логику, и CRUD, и пользовательский интерфейс больше не будет получать доступ к репозиториям (что, вероятно, следовало сделать с самого начала).

Как мне следует называть эти классы?Единственное, о чем я могу думать, это классы служб, но у меня есть реальные службы WCF в этом приложении, так что это приведет к путанице.Службы WCF также будут использовать эти классы, поэтому использование службой класса service кажется странным и сбивающим с толку.

Answer 1

Я также использую соглашение об именовании "Сервис".Это правда, что термин "сервис" стал очень перегруженным в отрасли, но он имеет наибольший смысл.Разработчики, просматривающие код, должны быть в состоянии определить разницу между службой приложения / Домена и службой WCF, и хотя вызов службы WCF другими классами служб может показаться запутанным, я думаю, вы обнаружите, что это не так.Идея сервиса заключается в том, что это код, который выполняет функцию и доступен для использования другим кодом.Это может быть внутренняя служба, или это может быть служба, предоставляемая извне через http или что-то еще.Но идея того, что делает код, та же самая.

Answer 2

Если ваши "сервисы" организуют бизнес-логику с использованием нескольких объектов домена, вы, скорее всего, реализуете Рисунок фасада - так что, возможно, вы можете назвать их с помощью этого суффикса, например OrderManagementFacade

Answer 3

Из вашего описания звучит так, как будто классы WCF на самом деле реализуют сервис ведущий.Обычно я называю такие классы суффиксом "ServiceHost".Это прекрасно отделяет их от реальных классов обслуживания.

Так, например, у вас была бы ваша бизнес-логика в классе с именем "CustomerService", а соответствующий класс WCF был бы назван "CustomerServiceHost".