Какую архитектуру выбрать (службы WCF, логика на стороне сервера)

Question

Я разрабатываю логику на стороне сервера для обработки запросов и ответа на данные на внешний сервер, а также на прямые подключения к мобильному приложению.

Я внедрил класс SessionContext, который в основном гарантирует, что в каждой базе данных есть соответствующая запись сеанса в каждой вызываемой услуге (с исключением для случаев забытых паролей и т. Д.).

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

Я придумал этот код, но почему-то я не чувствую себя хорошо - слишком много кода для каждого метода обслуживания. Есть ли какие-нибудь умные трюки, которые я мог бы реализовать, чтобы сделать его короче и легче читать/кодировать?

Текущая реализация будет использовать класс EventLogic для регистрации события в таблице событий. В какой-то момент некоторые события могут быть связаны с сеансом, поэтому я передаю eventLog как параметр SessionContext (чтобы создать связь между событием и сеансом). SessionContext сохраняет данные сущности при успешном удалении ... У меня есть ощущение, что что-то не так с моим дизайном.

public Session CreateUser(string email, string password, System.Net.IPAddress ipAddress) 
{ 
    using (var eventLog = new EventLogic()) 
    { 
     try 
     { 
      eventLog.LogCreateUser(email, password, ipAddress); 

      using (var context = SessionContext.CreateUser(eventLog, email, password, ipAddress)) 
      { 
       return new Session() 
       { 
        Id = context.Session.UId, 
        HasExpired = context.Session.IsClosed, 
        IsEmailVerified = context.Session.User.IsEmailVerified, 
        TimeCreated = context.Session.TimeCreated, 
        PublicUserId = CryptoHelper.GuidFromId(context.Session, context.Session.UserId, CryptoHelper.TargetTypeEnum.PublicUser), 
        ServerTime = context.Time 
       }; 
      } 
     } 
     catch (Exception e) 
     { 
      eventLog.Exception(e); 
     } 
    } 
} 

Answer 1

Вы должны рассмотреть возможность использования что-то вроде SLF4J + LogBack (например) для регистрации.

Если ваши классы следуют SRP, вы должны иметь не более одного типа вызова, например LogCreateUser для вашего приложения. И это означает, что нет необходимости извлекать логику регистрации в новый класс.