0

在学习 MVVM 时，我在 Microsoft Virtual Academy 看到了一个在线课程，Ben Riga 在下面编写了代码。我想知道的是以下问题：

使用名为 IDataService 的接口有什么好处？在模型类的方法或视图模型类中获取数据会导致代码更少。一定有一些我无法弄清楚的未来好处。有人可以为我解释一下吗？

模型：

public class CommonDataItem
{
    public DataItem(string uid)
    {
        Uid = uid;
    }
    public string Uid
    {
        get;
        private set;
    }
// Other properties ...
}

public interface IDataService
{
    void GetItem(Action<CommonDataItem> callback, 
        string uid);
}

public class DataService : IDataService
{
    public void GetItem(Action<CommonDataItem>
        callback, string uid)
    {
        // Retrieve the data from the actual source
        // ...
        var item = new DataItem(...);
        callback(item);
    }
}

视图模型：

public class MainViewModel : ViewModelBase
{
    private readonly IDataService _dataService;
    public const string Title_PropertyName = "Title";
    private string _title = string.Empty;
    public string Title
    {
        get { return _title; }
        set
        {
            if (_title == value)
            return;
            _title = value;
            RaisePropertyChanged(Title_PropertyName);
        }
    }

    // Constructor...
    public MainViewModel(IDataService dataService)
    {
        _dataService = dataService;
        _dataService.GetData(
            (item) =>
            {
                Title = item.Title;
                });
    } 
}
4

2 回答 2

0

我认为 IDataService 的目标就像一个典型的 Interface ：创建一个将定义和实现分开的层，这样您就可以在需要时更改 DataService 类，而无需更改使用它的逻辑。

于 2013-05-07T03:13:56.717 回答
0

First of all as usual in MVVM you do not have to do something, it is a recommendation or best practice. In general you are free to code the data access into your view model - and to do so might be a good practice for small projects or prototypical implementations.

However, you should consider that this also has some drawbacks. The reason for implementing a data service is that this component is reusable and even might be usable in other scenarios like an MVC application. Furthermore, it separates out the concern of getting model from a data store.

The reason for implementing an IDataService is that you can exchange the implementation when you need to, e.g. for supplying design time data. When you need this, you also have to consider the inversion of control pattern that heavily relies on interfaces. In this case also a IOC container might be interesting, although not necessary.

But, first of all the above are recommendations, patterns, design guidelines, and best practices that give you the freedom to design an application that best fits your requirements.

Edit: size of the data service

The design and scope of your data service depends on your application and it's requirements. It can range from a single data service for all you models to one data service per model. Furthermore, the design of you data service interfaces may be a separate decision. One service class can implement several service interfaces, thus allowing for hiding certain aspects (methods) of the implementation from the user.

When designing a data service you should look into the unit of work and repository patterns. There are several sample implementations around.

If you just need a very simple unit of work pattern that is based on a single query you can have a look at my blog, where I wrote about turning an IQueryable into a unit of work pattern. However, this fits only very simple cases, generally a complete implementation with a repository and a proper unit of work item is more advisably.

于 2013-05-07T04:18:38.647 回答