我习惯于使用 N-Tier 架构进行开发，即数据访问层、业务逻辑层等
任何人都可以就我的业务逻辑的最佳位置提供任何建议或链接吗？
我是否将所有这些放入我的 Silverlight 应用程序的 Models 文件夹中的类中？
保罗
【问题讨论】：
标签： silverlight mvvm silverlight-5.0
我遇到了同样的问题并决定这样做： 我在 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();
}
}
这种方法可以帮助我们：
【讨论】：
这是一个很好的问题，答案部分取决于项目的复杂性和开发人员的品味。
我见过的一些 MVVM 项目把所有东西都放在了 VM 部分，所以 View 的 .cs 文件是空的（因为每个人都知道'代码隐藏'是邪恶的）和模型文件包含被动的“存储类”（即基本上具有封装的 C 结构）。
对于一些简单的项目（例如几乎没有任何逻辑的查看器）来说，它可能是一个不错的选择。但它会导致类似 blob 的视图模型试图做所有事情，如果您的项目有任何复杂性，这是无法管理的。
Reed Copsey 的回答（业务逻辑/数据访问应该与 View/ViewModel 解耦）对于具有任何显着复杂性的项目来说是最佳解决方案。
【讨论】：
业务逻辑以及数据通常是 MVVM 中模型层的一部分。 View 是视觉效果，而 ViewModel 是让您使用业务特定逻辑和数据的“粘合剂”。
任何特定于域或业务的东西都应该可以被其他应用程序重用，使用其他架构。
【讨论】：