C'è una separazione netta dei miei strati con questo tentativo di Domain Driven Design in XAML e C #

Question

C'è una separazione netta dei miei strati con questo tentativo di Domain Driven Design in XAML e C #

#1 da (3 voti)

2

Sto lavorando su un'applicazione. Sto usando una miscela di TDD e DDD. Sto lavorando sodo per separare i livelli della mia applicazione ed è qui che arriva la mia domanda.

La mia soluzione è strutturata come segue

Solution
    MyApp.Domain (WinRT class library)
        Entity (Folder)
            Interfaces(Folder)
                IPost.cs (Interface)
            BlogPosts.cs(Implementation of IPost)
        Service (Folder)
            Interfaces(Folder)
                IDataService.cs (Interface)
            BlogDataService.cs (Implementation of IDataService)
    MyApp.Presentation(Windows 8 XAML + C# application)
        ViewModels(Folder)
            BlogViewModel.cs
        App.xaml
        MainPage.xaml (Contains a property of BlogViewModel
    MyApp.Tests (WinRT Unit testing project used for my TDD)

Quindi ho intenzione di utilizzare il mio ViewModel con l'interfaccia utente XAML

Sto scrivendo un test e definisco le mie interfacce nel mio sistema e ho il seguente codice fino ad ora.

    [TestMethod]
    public void Get_Zero_Blog_Posts_From_Presentation_Layer_Returns_Empty_Collection()
    {
        IBlogViewModel viewModel = _container.Resolve<IBlogViewModel>();

        viewModel.LoadBlogPosts(0);

        Assert.AreEqual(0, viewModel.BlogPosts.Count, "There should be 0 blog posts.");

    }

viewModel.BlogPosts è un ObservableCollection<IPost>

Ora .. il mio primo pensiero è che mi piacerebbe che il metodo LoadBlogPosts sul ViewModel richiamasse un metodo statico sull'entità BlogPost.

Il mio problema è che ho bisogno di iniettare IDataService nell'oggetto Entity in modo che promuova l'accoppiamento lento. Ecco le due opzioni con cui sto combattendo:

Non utilizzare un metodo statico e utilizzare un metodo membro sull'entità BlogPost. Chiedi a BlogPost di prendere un IDataService nel costruttore e utilizzare dependency injection per risolvere l'istanza di BlogPost e l'implementazione di IDataService .
Non utilizzare l'entità per chiamare IDataService . Metti il IDataService nel costruttore del ViewModel e usa il mio contenitore per risolvere il IDataService quando il modello di vista è istanziato.

Quindi con l'opzione uno i livelli appariranno come questo

ViewModel(Presentation layer) -> Entity (Domain layer) -> IDataService (Service Layer)

o

ViewModel(Presentation layer) -> IDataService (Service Layer)

c# domain-driven-design soa mvvm

posta Buddy James 25.11.2012 - 00:32

fonte

1 risposta

Leggi altre domande sui tag c# domain-driven-design soa mvvm

Design Patterns - Service Layer Come testare se un algoritmo di hash è buono? [duplicare]

score 3 · Accepted Answer

Non sono sicuro di aver capito tutto ciò che hai scritto. Preferisco che il mio oggetto dominio non sappia troppo sugli oggetti di persistenza, ma c'è un enorme dibattito su questo nella comunità di ddd. Questo è il modo in cui faccio le cose di solito:

viewModel prende una dipendenza da un servizio applicativo (es: BlogService). Il bogService accetta una dipendenza da un servizio di repository (es: RepositoryBlog).

blogService viene utilizzato per recuperare i dati attraverso il proprio repository e avviare l'azione della radice aggregata. La struttura dell'iniettore delle dipendenze potrebbe occuparsi di tutte le iniezioni di dipendenza.

Quando pensi all'iniezione di dipendenza, potresti pensare alla vita del tuo oggetto. se la dipendenza è uguale o maggiore dell'oggetto, pensaci, altrimenti potresti preferire l'iniezione attraverso il metodo.

pseudoCode con Article come aggregateroot:

ViewModel

ViewModel (IArticleService service) 
{
    _service=service;
}

public PostNewArticle(string postText, Guid idUser)
{
    _service.PostNewArticle(postText, idUser)
}

SERVIZIO DI APPLICAZIONE

ArticleService(IRepositoryArticle repository )
{
    _repository = repository;
}

public PostNewArticle(string postText, Guid idUser)
{
    var user= _repository.GetUser(idUser);

    var article = user.CreateArticle(postText);

    _repository.SaveArticle(article);
}

DOMINIO

User()
{}

public Article CreateArticle(string text)
{
    if(!user.Active)
       throw new Exception("user not active")

     return new Article(text);
}

------------------

Article(string text)
{
    _text= text;
}

Spero che ti sia stato d'aiuto.