2011-10-03 14 views
6

Sto costruendo un'applicazione con seguente architettura:In DDD dove mantenere le eccezioni personalizzate (eccezioni dell'applicazione)? Nel livello Infrastruttura?

UI - Applicazione - Dominio - Infrastruttura

Ho un Application Layer che hanno bisogno di utilizzare le eccezioni personalizzate. Dove tengo queste eccezioni personalizzate? Nel livello Infrastruttura? Il problema è che il mio livello di applicazione non ha riferimento al livello dell'infrastruttura.

Qual è il modo corretto?

Aggiornamento:

Ecco il mio codice che un'eccezione in Application Layer:

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))); 
    } 
} 

Anche ImageSettings è un ConfigurationSection è nel mio Application Layer perché lo usa. Non vedo l'altro modo in cui posso trasferire i miei ImageSettings (che dovrebbero rimanere in Infrastrucuture Layer) a Infrastructure Layer, qualcuno può aiutarti?

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"]; 
     } 
    } 
} 

risposta

0

Hai un livello in cui le preoccupazioni trasversali (come la registrazione o l'iniezione di dipendenza) si rivolgono, e che fa riferimento tutti gli altri progetti nella vostra soluzione? Se è così, è qui che dovresti inserire queste eccezioni personalizzate. Immagino che con "infrastruttura di livello" intendi realmente questo strato trasversale, ma in tal caso, sembra strano che il tuo livello di applicazione non stia facendo riferimento a esso.

In alternativa, è possibile mantenere queste eccezioni nel livello dell'applicazione stesso, a condizione che queste eccezioni siano utilizzate solo da quel livello e, forse, anche dallo strato dell'interfaccia utente.

+0

riferimento Application Infrastructure. L'applicazione non fa riferimento a infrastruttura. Penso che questo sia il corretto ... –

0

Questo è probabilmente correlato al previous question. Le eccezioni fanno parte del contratto definito dal livello applicazione ed è implementato dall'infrastruttura (DIP e Onion architecture). Dovrebbero essere definiti in termini di applicazione e gestiti dall'applicazione, ma generati dall'infrastruttura. Ad esempio, nel codice di applicazione:

public class NotificationException : Exception {...} 

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

E in infrastrutture:

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

il tuo scenario è molto diverso dal mio scenario ... vedi aggiornamento per favore ... –

0

Acaz Souza - siete errato nel dire la sognerei Application Layer riferimento il livello di infrastruttura. Ti suggerisco di leggere "Domain Driven Design Quickly", che è disponibile gratuitamente da InfoQ.

Guardare lo schema seguente, che illustra il mio punto.

Grazie

Domain Driven Design - Layers

+0

Ehi Ronnie, questo diagramma non è un progetto basato sul dominio come ho capito, è guidato dall'infrastruttura. Gli oggetti di dominio (progetti) non devono avere una dipendenza dall'infrastruttura in DDD .. utilizzando ORM per ** Generare ** classi POCO ed entità non richiede una dipendenza di progetto su Infrastruttura (livello di accesso ai dati), è un pre -processing, pre-costruzione preoccupazione .. –

+0

Per quanto riguarda la dipendenza dell'applicazione su Infrastructure, l'infrastruttura sembra comprendere preoccupazioni che vanno oltre l'implementazione di servizi di dominio e applicazioni e l'accesso a server, gateway e simili. Cioè, "System.Net.HttpContext" è non fa parte del ** livello ** infrastruttura, ma è sicuramente qualcosa a cui il mio livello applicativo dipende. Quindi posso solo presumere che questo diagramma stia designando. NET Framework Assembly come parte del livello dell'infrastruttura. ma questa non è un'infrastruttura che sta implementando qualcosa nel tuo dominio .. quindi è discutibile .. –

+0

Nel libro "Domain Driven Design Quickly", gli esempi hanno il livello dell'applicazione che fa riferimento al livello dell'infrastruttura, ad es. "Il livello dell'applicazione è un sottile strato che si trova tra l'interfaccia utente, il dominio e l'infrastruttura, che interagisce con l'infrastruttura del database durante le operazioni di accesso ... ecc." (Pagina 39) – Ronnie

Problemi correlati