NMackay wrote:
After evaluating different ORM's we've finally purchased LLBLGen (and Profiler) as it ticked the most boxes and because of the excellent support we got when evaluating the product (thanks for putting up with the constant queries Frans).
Thanks for the feedback !
NMackay wrote:
Our new architecture is based round WPF but we want to take the route MVVM to a certain level to allow some amount of decoupling the XAML from the code behind although I don't advocate zero code behind (why should code that just deals with UI control specific behaviour be in the view model) unlike some of the people pushing the pattern.
I agree. MVVM could be complex for simple UI tasks and if not programmed wisely it could grow in a bad way.
NMackay wrote:
Does anyone have any samples on using LLBLGen in an MVVM scenario?
No AFAIK.
NMackay wrote:
Most of the MVVM samples treat the model as a single entity (one table) but in practice is might involve data from three entities, you'll notice all the MVVM samples are pitifully basic when it comes to the actual CRUD operations and data.
For complex model requirements you could use TypedLists, TypedViews, DynamicLists, or even your own DTO objects.
NMackay wrote:
Do you need an adapter class (model) to separate the LLBLGen side from the model or could you treat a Typedview/entity etc as the model part ?
You can use whatever is bindable to the view. All you need is using ObservableCollection with your LLBLGen generated entities. Also, I think that for WPF you need the EntityCollection implements INotifyPropertyChanging. This is easily added. See this:
http://llblgen.com/tinyforum/Messages.aspx?ThreadID=19851
NMackay wrote:
Just curious to see others here thought and what the LLBLGen guys on the best way with MVVM.
LLBLGen objects are ready to be used in MVVM, similar to the way you use them as the model in a MVC application (MVVM is just a specialized form of MVC).
NMackay wrote:
The whole MVVM thing is a bit of a mess, I understand the design pattern and in WPF you need to make use of user controls or it becomes a mess but the numerous frameworks and little support for VB.NET (we heavily use vb.net) make it a bit frustrating, also some of the people pushing it seem to be more interesting in selling books.
As I understand MVVM, it's some pattern based on MVC to take advantage of WPF/Silverlight applications. So you need it if you are using one of those. For the rest of apps I think you can live with MVC or similar. Actually, there are debates about pros/cons, differences and similarities between those patterns.
Example of a very simple MVVM app using LLBLGen entities:
ViewModel class
namespace WpfApp
{
public class CustomerViewModel : DependencyObject, INotifyPropertyChanged
{
public CustomerViewModel()
{
LoadCustomers();
}
private void LoadCustomers()
{
Customers = new ObservableCollection<CustomerEntity>();
using (var adapter = new DataAccessAdapter())
{
var metaData = new LinqMetaData(adapter);
var temp = metaData.Customer.ToList();
// fill my ObservableCollection
foreach (var cust in temp)
{
Customers.Add(cust);
}
}
}
public ObservableCollection<CustomerEntity> Customers { get; set; }
public event PropertyChangedEventHandler PropertyChanged;
protected void OnPropertyChanged(string name)
{
if (PropertyChanged != null)
{
PropertyChanged(this, new PropertyChangedEventArgs(name));
}
}
}
}
Code behind
public partial class MainWindow : Window
{
CustomerViewModel _viewModel;
public MainWindow()
{
InitializeComponent();
_viewModel = new CustomerViewModel();
DataContext = _viewModel;
}
}
xaml
<ComboBox Height="50" Width="200" ItemsSource="{Binding Path=Customers}" DisplayMemberPath="CompanyName" SelectedValuePath="CustomerId" />
