业务逻辑在 MVVM 中的位置

Question

我习惯于使用 N 层架构进行开发，即数据访问层、业务逻辑层等

任何人都可以提供有关我的业务逻辑的最佳位置的任何建议或链接吗？

我是否将所有这些内容都放入 Silverlight 应用程序的"模型"文件夹中的类中？

保罗

Answer 1

业务逻辑以及数据通常是 MVVM 中模型层的一部分。 视图是视觉对象，视图模型是"胶水"，可让您使用特定于业务的逻辑和数据。

特定于

域或业务的任何内容都应可由其他应用程序使用其他体系结构重用。

Answer 2

这是一个很好的问题，答案部分取决于项目的复杂性和开发人员的品味。

我见过的一些 MVVM 项目将所有内容都放在 VM 部分，因此 View 的 .cs 文件是空的（因为每个人都知道"代码隐藏"是邪恶的），模型文件包含被动的"存储类"（即基本上带有封装的 C 结构）。

对于一些简单的项目（例如几乎没有任何逻辑的查看器），它可能是一个不错的选择。但是，如果您的项目有任何复杂性，这将导致类似 blob 的视图模型尝试执行所有操作，这是无法管理的。

---

Reed Copsey的答案（业务逻辑/数据访问应与View/ViewModel分离）是具有任何重大复杂性的项目的最佳解决方案。

Answer 3

我遇到了同样的问题，决定走这条路：我在 MVC 中创建了类似控制器的类（使用我的模型执行一些操作），并在所有 ViewModel 中使用它们。

例如：我们的应用程序有一个书籍列表。我们需要添加/编辑/删除它们。

所以我们有一个模型：

public class Book 
{
    public int BookId { get; set; }
    public string Title { get; set; }
    public string Author { get; set; }
}

然后我们有一个控制器类：

public class BookController 
{
    string dbPath = ...;
    public void AddBook(string title, string author)
    {
        var book = new Book() { Title = title, Author = author };
        AddBook(book);
    }
    public void DeleteBook(int id)
    {
        using (var db = new SQLiteConnection(dbPath))
        {
            db.Delete<Book>(id);
        }
    }
    public void DeleteBook(Book book)
    {
        using (var db = new SQLiteConnection(dbPath))
        {
            DeleteBook(book.BookId);
        }
    }
    public List<Book> GetAllBooks()
    {
        using (var db = new SQLiteConnection(dbPath))
        {
            return db.Table<Book>().ToList();
        }
    }
    public Book FindBook(string title, string author, int id)
    {
        .....
    }
}

现在我们可以在需要的任何地方使用它，例如：

public class BookListViewModel : ViewModelBase 
{
    public BookListViewModel() 
    {
        GetData();    
    }
    private void GetData()
    {
        BookController bc = new BookController(); // here we start using our controller. 
        _books = new List<Book>();
        _books = bc.GetAllBooks();
     }
}

这种方法有助于我们：

1. 单独保留所有业务逻辑（在控制器类中）
2. 避免代码重复