I\'m working on an application. I\'m using a mixture of TDD and DDD. I\'m workin

Question

I'm working on an application. I'm using a mixture of TDD and DDD. I'm working hard to separate the layers of my application and that is where my question comes in.

My solution is laid out as follows

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)
So I'm planning to use my ViewModel with the XAML UI

I'm writing a test and define my interfaces in my system and I have the following code thus far.

    [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 is an ObservableCollection<IPost>

Now.. my first thought is that I'd like the LoadBlogPosts method on the ViewModel to call a static method on the BlogPost entity.

My problem is I feel like I need to inject the IDataService into the Entity object so that it promotes loose coupling. Here are the two options that I'm struggling with:

Not use a static method and use a member method on the BlogPost entity. Have the BlogPost take an IDataService in the constructor and use dependency injection to resolve the BlogPost instance and the IDataService implementation.

Don't use the entity to call the IDataService. Put the IDataService in the constructor of the ViewModel and use my container to resolve the IDataService when the viewmodel is instantiated.

So with option one the layers will look like this

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

or

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

Explanation / Answer

I am not sure I understood eveything you wrote. I prefer my domain object not to know too much about persistence objects, but there is a huge debate on this in the ddd community. This is how I do things usually :

The viewModel takes a dependency on a application service (eg : BlogService). The bogService takes a dependency on a repository service ( eg: RepositoryBlog).

blogService is used to fetch data through its repository, and start the action of the aggregate root. The dependency injector framework might take care of all your dependency injection.

When thinking about injection of dependence, you might think of the lifetime of your object. if the dependency equals or is greater than the object, think ctor, otherwise, you might prefer injection through the method.

pseudoCode with Article as the aggregateroot:

VIEWMODEL

ViewModel (IArticleService service)
{
_service=service;
}

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

ArticleService(IRepositoryArticle repository )
{
_repository = repository;
}

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

var article = user.CreateArticle(postText);

_repository.SaveArticle(article);
}
DOMAIN

User()
{}

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

return new Article(text);
}

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

Article(string text)
{
_text= text;
}
Hope it helped.

Related Questions

Navigate

• Browse (All)
• Browse I
• Subjects