c# - хранить - Наименование классов бизнес-логики




рекомендации по написанию кода (2)

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

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

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

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


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





business-logic-layer