我习惯于使用 N 层架构进行开发,即数据访问层、业务逻辑层等
任何人都可以提供有关我的业务逻辑的最佳位置的任何建议或链接吗?
我是否将所有这些放入 Silverlight 应用程序的 Models 文件夹中的类中?
保罗
我习惯于使用 N 层架构进行开发,即数据访问层、业务逻辑层等
任何人都可以提供有关我的业务逻辑的最佳位置的任何建议或链接吗?
我是否将所有这些放入 Silverlight 应用程序的 Models 文件夹中的类中?
保罗
业务逻辑以及数据通常是 MVVM 中模型层的一部分。View 是视觉效果,而 ViewModel 是让您使用业务特定逻辑和数据的“粘合剂”。
任何特定于领域或业务的东西都应该可以被其他应用程序重用,使用其他架构。
我遇到了同样的问题并决定这样做:我在 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 文件是空的(因为每个人都知道 'code-behind' 是邪恶的</sarcasm>)并且 Model 文件包含被动的“存储类”(即 C基本上带有封装的结构)。
对于一些简单的项目(例如几乎没有任何逻辑的查看器),它可能是一个不错的选择。但它会导致类似 blob 的视图模型试图做所有事情,如果您的项目有任何复杂性,这是无法管理的。
Reed Copsey 的回答(业务逻辑/数据访问应该与 View/ViewModel 解耦)是具有任何显着复杂性的项目的最佳解决方案。