Interactions between Service, Model, and Repository Layers

Question

I have been tasked with the undertaking of translating an application from SharePoint to .NET. I am concerned with doing it the right way, so I got an architecture book to read up on patterns and practices.

I've tried to model everything out using Domain Driven Design. I have a Model that represents my world, a Repository to store it in the database, and a Service layer to interact with UI (which is WebForms, because I have 0 experience in MVC and am already hardly treading water with this undertaking).

I am having difficulty grasping the correct way for the layers to interact. My understanding is that the Model should be the base of everything. It references nothing, other layers reference it.
Question 1: Is that right?

I'm getting really concerned with the Service Layer. I'm noticing that I'm developing a very anemic Model, for two reasons: 1, my Model doesn't reference Repository, so I can't store anything via the Model. 2, I am trying to do things as they happen (ie. I add an object to a list of objects, so I store it in the DB one at a time instead of all at once when the user is done adding the objects). So a lot of the work is being done between the Service and Rep layers, with the Model just being there and looking nice.

I'm starting to worry--I'm early in the development, but I am the one being looked at to be the architect of all this. I don't want a maintenance nightmare (I expect this application will be used for years). As always, time is a concern, and I have not been able to prepare/learn effectively. Any help would be swell. :-)

Answer 1

Model should be the base of everything. It references nothing, other layers reference it. Question 1: Is that right?

The typical way to enforce separation between the domain model and the persistence system is to define repositories. Persistence however is not a part of the domain model.

Your models should call methods defined by the repository

For example consider this totally fake repository:

// Repository
public class SharepointRepository
{
   void SaveWidget(); // Implement
}

So the repository is only concerned with loading and saving data, they don't contain any of your domain logic at all.

However if your model is tightly bound to the repository, you've got a separation of concerns issue.

So in this case, Dependency Injection becomes useful. With the prior example, your model would have to explicitly instantiate SharePointRepository and invoke methods. A cleaner way of doing this so that your model doesn't care is to inject the dependency of your repository at runtime.

namespace YourApp.Domain.Abstract
{
    public interface ISharePointRepository
    {
        void SaveWidget();
    }
}

Based on this interface, you could build a concrete implementation and inject the dependency to the concrete implementation at run time.

namespace YourApp.Domain.Concrete
{
    public class SqlSharePointRepository : ISharePointRepository
    {
        void SaveWidget()
        {
          // Code that Saves the widget using the managed sql provider
        }

    }
}

So on your web form:

When you are collecting data, your model will be hydrated with data from the form, and will invoke a repository method, however the repository itself would have been injected into the asp.net application at runtime, so you could change SqlSharePointRepository to RavenDbRepository without breaking your app.

To see how to bind your repository in Webforms see this SO Post: How can I implement Ninject or DI on asp.net Web Forms?

With MVC the controller is responsible for the gap you think your are experiencing. But as to your questions and based on your current design, the model should invoke repository operations, however the repository itself should be loosely coupled.