|
There are, of course, about a million ways to implement a data access layer in any N-tier application. Some are better than others and most people have their own favorite practices and patterns. But is there a practice or pattern that anyone can think of that is somehow specifically well suited for use in SoapBox Core or SoapBox Core addins/parts? Maybe there is some way to leverages the power of MEF or some other attribute of the SoapBox Core machinery to create a particularly robust data access layer. |
|
SoapBox Core is, by definition, an MVVM framework. In fact, it doesn't ship with any implementation of a Model, so it's really a View-ViewModel framework. (In the case of SoapBox Snap, the Data Access Layer is provided by SoapBox Protocol). Your persistence layer is usually either encapsulated within your Model (if you use the ActiveRecord pattern) or is a service only known to your Model (if you use the Repository or Unit of Work pattern). Given that SoapBox Core is Model-Agnostic, I'm tempted to say that a DAL doesn't belong there. That doesn't mean there couldn't be a separate SoapBox.Model framework, but I really think you should be able to completely mix and match SoapBox Core with any Model. To answer your question in the title, from experience, I suggest combining the following:
Your repository looks like this:
Your model layer logic can look like this:
|