2011-10-03 14 views
6

Buduję aplikację z poniższej architekturze:W DDD gdzie zachować niestandardowe wyjątki (wyjątki aplikacji)? W warstwie infrastruktury?

UI - Skarga - domeny - Infrastruktura

Mam warstwa aplikacji, które muszą korzystać z niestandardowych wyjątki. Gdzie trzymam te niestandardowe wyjątki? W warstwie infrastruktury? Problem polega na tym, że moja warstwa aplikacji nie ma odniesienia do warstwy infrastruktury.

Jaki jest prawidłowy sposób?

Aktualizacja:

Oto mój kod, który rzucać wyjątek w warstwie aplikacji:

public void InsertNewImage(ImagemDTO imagemDTO) 
{ 
    if (isValidContentType(imagemDTO.ImageStreamContentType)) 
    { 
     string nameOfFile = String.Format("{0}{1}", Guid.NewGuid().ToString(), ContentTypeHelper.GetExtension(imagemDTO.ImageStreamContentType)); 

     string path = String.Format("{0}{1}", ImageSettings.PathToSave, nameOfFile); 

     _fileService.SaveFile(imagemDTO.ImageStream, path); 

     Imagem imagem = new Imagem() 
          { 
           Titulo = imagemDTO.Titulo, 
           Descricao = imagemDTO.Descricao, 
           NomeArquivo = nameOfFile 
          }; 

     _imagemRepository.Add(imagem); 

     _dbContext.SaveChanges(); 
    } else 
    { 
     throw new WrongFileTypeException(String.Format("{0} is not allowed.", ContentTypeHelper.GetExtension(imagemDTO.ImageStreamContentType))); 
    } 
} 

Nawet ImageSettings jest ConfigurationSection jest w moim warstwie aplikacji, ponieważ używa go. Nie widzę innego sposobu, w jaki mogę przenieść moje ustawienia ImageSettings (które powinny pozostać w Infrastrukture Layer) do warstwy infrastruktury, ktoś może pomóc?

public class ImageSettings : ConfigurationSection 
{ 
    /// <summary> 
    /// Caminha onde será salvo as imagens 
    /// </summary> 
    [ConfigurationProperty("pathToSave", IsRequired = true)] 
    public string PathToSave 
    { 
     get { return (string)this["pathToSave"]; } 
     set { this["pathToSave"] = value; } 
    } 

    /// <summary> 
    /// Extensões permitidas pra upload 
    /// </summary> 
    [ConfigurationProperty("allowedExtensions", IsRequired = true)] 
    public string AllowedExtensions 
    { 
     get { return (string)this["allowedExtensions"]; } 
     set { this["allowedExtensions"] = value; } 
    } 

    /// <summary> 
    /// Tamanho das imagens 
    /// </summary> 
    [ConfigurationProperty("imageSize")] 
    public ImageSizeCollection ImageSize 
    { 
     get 
     { 
      return (ImageSizeCollection)this["imageSize"]; 
     } 
    } 
} 

Odpowiedz

0

Czy masz warstwę gdzie obawy przekrojowe (takie jak rejestrowanie lub wstrzykiwania zależności) zostały uwzględnione, a które odwołuje się do wszystkich innych projektów w rozwiązania? Jeśli tak, to powinieneś umieścić te niestandardowe wyjątki. Domyślam się, że przez "warstwę infrastruktury" rozumiesz tę przekrojową warstwę, ale jeśli tak, to dziwne wydaje się, że twoja warstwa aplikacji jej nie odwołuje.

Alternatywnie można zachować te wyjątki w samej warstwie aplikacji, pod warunkiem, że te wyjątki są używane tylko przez tę warstwę i być może również przez warstwę interfejsu użytkownika.

+0

odniesienia Infrastruktura aplikacji. Aplikacja nie referencyjna INfrastruktura. Myślę, że to jest poprawne ... –

0

Jest to najprawdopodobniej związane z numerem previous question. Wyjątki są częścią umowy definiowanej przez warstwę aplikacji i są implementowane przez infrastrukturę (DIP i Onion architecture). Powinny być zdefiniowane w warunkach stosowania i obsługiwane przez aplikację, ale odrzucane z infrastruktury. Na przykład, w kodzie aplikacji:

public class NotificationException : Exception {...} 

public interface ICanNotifyUserOfSuccessfullRegistration { 
    /// <summary> 
    /// ... 
    /// </summary> 
    /// <exception cref="NotificationException"></exception> 
    void Notify(); 
} 

aw Infrastruktura:

public class SmsNotificator : ICanNotifyUserOfSuccessfullRegistration { 
    public void Notify() { 
     try { 
      // try sending SMS here 
     } catch(SmsRelatedException smsException) { 
      throw new NotificationException(
          "Unable to send SMS notification.", smsException); 
     } 
    } 
} 
+0

Twój scenariusz jest bardzo różny od mojego scenariusza ... zobacz aktualizację prosze ... –

0

Acaz Souza - jesteś błędnie mówiąc shouldnt Warstwa aplikacji odwołać warstwę infrastruktury. Proponuję przeczytać "Domain Driven Design Quickly", który jest dostępny bezpłatnie w InfoQ.

Spójrz na poniższy diagram, który ilustruje mój punkt.

Dzięki

Domain Driven Design - Layers

+0

Hej Ronnie, ten diagram nie jest projektem opartym na domenie, jak rozumiem, jest napędzany infrastrukturą. obiekty domeny (projekty) nie powinny być zależne od infrastruktury w DDD .. z ORM na ** Generowanie ** klasy POCO i encje nie wymagają zależności projektu od infrastruktury (warstwa dostępu do danych), jest to pre - przetwarzanie, problemy przed budową .. –

+0

Jeśli chodzi o zależność aplikacji od infrastruktury, wydaje się, że ta infrastruktura obejmuje obawy wykraczające poza implementację usług domenowych i aplikacji oraz dostęp do serwerów sql, bramek itp. Oznacza to, że 'System.Net.HttpContext' jest nie jest częścią ** mojej ** warstwy infrastruktury, ale z pewnością jest to coś, na co moja warstwa aplikacji ma zależność. Mogę tylko założyć, że ten schemat wyznacza zespoły szkieletów .net jako część warstwy infrastruktury. ale to nie jest infrastruktura, która implementuje coś w twojej domenie .. więc jest wątpliwa .. –

+0

W książce "Domain Driven Design Quickly" przykłady mają warstwę aplikacji odwołującą się do warstwy infrastruktury, np. "Warstwa aplikacji to cienka warstwa między interfejsem użytkownika, domeną i infrastrukturą, która współdziała z infrastrukturą bazy danych podczas operacji logowania ... itd." (Strona 39) – Ronnie