LLBL for the new age
omar wrote:
I choose to post this thread in "General Chat" so as not to be interpreted as a demand for feature specially that I touched (partially) upon this issue in a different thread.
Currently there is a clear and new trend in the .NET development universe and that is WPF/Silverlight.
The way it affects LLBL is on many dimensions:
1- LLBL entities provided rich support for the (classical) data binding under Winfroms and ASP.NET. With WPF, binding is a core concept that is designed to not only server data but many more things in the UI. Although LLBL entities/collection are still data-bound under WPF, they do not support the two interfaces necessary to take full advantage of WPF/Silverlight binding. Frans has recommended we write code/templates to add the implementation to the generated DAL. IMHO, WPF/SL binding deserves the same first class support as its predecessor's (Winforms/ASP.NET) had.
Template changes are planned for this (v3), where you can enable this feature through a setting in the designer (output setting values part on project properties). We just can't do everything at once unfortunately 
2- Silverlight 3/4 ushered SL into the LOB (Line of Business) applications. SL relies on RIA services (an implementation of WCF services developed by SL team) for all data access as SL does not have the ADO.NET API as part of its trimmed .NET framework. RIA services provide a design-time experience similar to what we have enjoyed with LLBL in terms of automating the DB changes into the code. Problem is VS's support for this automation is perfect for Entity Framework's Entity Model. So, changes to the DB is refreshed in the Entity Model and VS's RIA design time support would automatically pickup the changes and regenerate all the necessary classes (proxy classes...) for the consuming UI project. LLBL has proud itself under Winforms/ASP.Net with a true automated design time experience. With SL 3/4 and RIA, using LLBL is now proving to be more "manual" design-time work when compared to EF.
Let it first be said that the design experience for EF is also pretty bad: the wizard for ria services will run only once (so a changed model will require you to re-add the service) and only works if the edmx file is in the same project as the entities as we found out recently. (add to that that the context class name has to be equal to the entity container name in the CDSL part, otherwise the wizard (which actually is more of a dumb apprentice IMHO) can't find it) This is limiting as with poco classes for example you want the edmx / context files in a separate project, why else use poco?
We have planned to add RIA services support for llblgen pro in the coming months. Again, we can't do everything at once, so it's not done tomorrow. We have no idea if this 'wizard' will be useful, considering its severe limitations, so we'll look into adding a template for that too, but keep in mind that our primary goal is to provide data-access technology, not UI stuff.
3- The new design pattern "fashion" of MVVM is having all bloggers/books/articles preach MVVM as the best thing since the invention of sliced bread. All the hype aside, implementing MVVM in WPF/SL projects provides compelling benefits for testability and separation-of-concern that allows designers to work in parallel with UI developers. Many MVVM toolkits out there try to automate and guide developers into the best/right way to use the design pattern. A lot of them are preaching the benefits of shaping/flattening the entities (DTO anyone!!) so that Views are bound to these shaped/flattened entities. Again, WPF/SL developers using LLBL will want some guidance/templates/designer that could automate and ease the maintenance of these UI entities.
Which pattern to use seems to change every year, as it was only recently that people thought the MVP pattern was the way to go, although MS lagged a bit with their MVC (which is the same thing, but ego bickering between people who find themselves important resulted in a new name) based asp.net stuff.
We have no experience with MVVM. If these patterns focus on creating classes which contain several entities / subgraphs, designer support is not planned soon. If you can deal with them on a readonly basis using a typedlist like approach, we could look into it, however I fear this isn't going anywhere, because how to persist data back?
Thank you Frans for the detailed answer. I think your answers will resonate favorably among many of the LLBL loyalists (myself included 
)...
Concerning your question about how to presist data back in the MVVM pattern, the whole concept in MVVM is to provide an abstraction layer between the Views and the BL. Basically, its the ViewModel that gets the intemate knowledge of the BL and its services (including data persistence among other things).
The mindset here is that BL classes should be designed for Business Logic in mind while ViewModel classes are designed to server the UI (usually a 1:1 between a View and ViewModel). The Utopian case is for all communication between View and ViewModel to occur through XAML's binding with minimal or no-code behind in the view.
omar wrote:
Thank you Frans for the detailed answer. I think your answers will resonate favorably among many of the LLBL loyalists (myself included
Concerning your question about how to presist data back in the MVVM pattern, the whole concept in MVVM is to provide an abstraction layer between the Views and the BL. Basically, its the ViewModel that gets the intemate knowledge of the BL and its services (including data persistence among other things).
The mindset here is that BL classes should be designed for Business Logic in mind while ViewModel classes are designed to server the UI (usually a 1:1 between a View and ViewModel). The Utopian case is for all communication between View and ViewModel to occur through XAML's binding with minimal or no-code behind in the view.
Ok, so if I understand it correctly, UI oriented code is in the viewmodel classes, correct? If the viewmodel classes aren't entity classes, why do these interfaces have to be on the entities? Or are you saying, using the entity classes is also OK (but that would mean: no mvvm, correct?) (I ask, because I have no idea what MVVM is, with respect to MVC or MVP)
I think the viewmodel holds the data, while the view holds UI code.
The view binds to the viewmodel. The viewmodel is not aware of the view, but the view is aware of the viewmodel.
The only benefit is a logical separation between how how the application works with data(viewmodel), and how it displays data(view).
As you always say, Frans, it all boils down to a solution that is profitable and manageable. I'm still trying to see if that's the case for my solutions. Everyone seems to have their own personal rendition of MVVM (iow - there is no standard).
(edit: Forgot to add that viewmodels can be easily used in unit tests, without any ui.)
As for RIA Services, I look forward to ditching ef and using the llblgen pro framework with ria services. Anything I can do to help?
JRR wrote:
I think the viewmodel holds the data, while the view holds UI code.
The view binds to the viewmodel. The viewmodel is not aware of the view, but the view is aware of the viewmodel.
The only benefit is a logical separation between how how the application works with data(viewmodel), and how it displays data(view).
As you always say, Frans, it all boils down to a solution that is profitable and manageable.
Yes that's my conclusion as well, after doing some research into this area. We're thinking about adding a feature where you can model your ViewModels as well, as they're based on the entity model anyway (data has to be passed back/forth), but as there's no standard, generating this can be a bit of a pain because the user will often find the generated code not how s/he would have written it her/himself.
(edit: Forgot to add that viewmodels can be easily used in unit tests, without any ui.)
As for RIA Services, I look forward to ditching ef and using the llblgen pro framework with ria services. Anything I can do to help?
See: http://www.llblgen.com/tinyforum/GotoMessage.aspx?ThreadID=16377&MessageID=102594
Joined: 25-Oct-2005
Otis wrote:
Yes that's my conclusion as well, after doing some research into this area. We're thinking about adding a feature where you can model your ViewModels as well, as they're based on the entity model anyway (data has to be passed back/forth), but as there's no standard, generating this can be a bit of a pain because the user will often find the generated code not how s/he would have written it her/himself.
FWIW We would love to be able to use the LLBL designer to model ViewModels(or at least entities that aren't mapped to tables) though it would require us to buy more licences I guess
You're right that the generated code will not please everyone but you could same the same about the LLBL entities but I would have thought the answer would be much the same - play with the templates.
Joined: 24-Mar-2011
Frans,
I've spoken with you directly in the past but I thought I'd chip in here, hope you don't mind.
I don't want to get into the whole is WPF dead or not debate, it's in VS2012 with a lot more features so beyond that I don't know (VS2010 & 2012 IDE's are written in WPF), for LOB apps where you need the full .NET framework you’re looking at WPF or Winforms, a lot of management won't commit to large scale projects if the technology is considered end of life as is the case with Winforms (I know it does the job ok).
WPF gives us a lot of features Winforms doesn't, loose XAML loading etc opens many possibilities Winforms never could, resolution independence etc
If the solutions was lighter then Silverlight might be the better choice but it has limitations as it runs in a sandbox, HTML5 might be great but that’s way off been mature.
We're struggling with the decision over the ORM, we've found many solutions out there to be unsatisfactory, the one we're using evaluating is bug ridden.
I keep getting drawn back to LLBLGen pro but myself and others in the team are struggling with your stance on WPF, it's almost like it's hated and you wish to disregard it as a solution, maybe your waiting to see where the dev landscape goes but the fact is the uptake on WPF is increasing significantly for business applications.
Some WCF & WPF samples for example of just LLBLGen with WCF would be good, it would give us the reassurance it all works together fine.
I'd like to give LLBLGen a go but my main worry is since it's WPF we'll have to code workarounds and you’re not interested in supporting it, if it was Winforms or ASP I wouldn't hesitate is using it.
It used to be that choosing the type of interface was the headache, it's the other way round now 
WPF is good in 2010, ignore the designer, I just use it to preview the XAML
p.s
I personally think the whole MVVM thing is a bit of a nightmare btw, pick a standard and stick with it but don't force it down people's throats, it'll probably get to the stage that if you’re not using MVVM you won't get decent support from some vendors.
edit: I ended up evaluating LLBLGEn Pro with WPF and the binding seems to work fine with WPF.
Scaramanga wrote:
Frans, I've spoken with you directly in the past but I thought I'd chip in here, hope you don't mind.
I don't want to get into the whole is WPF dead or not debate, it's in VS2012 with a lot more features so beyond that I don't know (VS2010 & 2012 IDE's are written in WPF), for LOB apps where you need the full .NET framework you’re looking at WPF or Winforms, a lot of management won't commit to large scale projects if the technology is considered end of life as is the case with Winforms (I know it does the job ok).
The VS.NET IDE is largely still C++ and WPF is used in some areas but not in a lot of other cases. Windows vista/7 have a different WPF-like implementation than WPF itself, as WPF is considered too slow.
I keep getting drawn back to LLBLGen pro but myself and others in the team are struggling with your stance on WPF, it's almost like it's hated and you wish to disregard it as a solution, maybe your waiting to see where the dev landscape goes but the fact is the uptake on WPF is increasing significantly for business applications.
It's difficult to make the decision now whether WPF will be the way to go. This is MS fault in every way, they dropped the ball several times and refuse to for example refactor WPF to make it perform better, and on top of that, Silverlight gets so powerful that one wonders why one would pick WPF over silverlight.
Some WCF & WPF samples for example of just LLBLGen with WCF would be good, it would give us the reassurance it all works together fine.
yes, understood. We'll look into adding more examples which are more suited towards modern technology in the future. We didn't do that in recent years as we've been bitten too many times by the 'various new stuff' MS releases and then abandones (dynamic data anyone?)
p.s I personally think the whole MVVM thing is a bit of a nightmare btw, pick a standard and stick with it but don't force it down people's throats, it'll probably get to the stage that if you’re not using MVVM you won't get decent support from some vendors.
edit: I ended up evaluating LLBLGEn Pro with WPF and the binding seems to work fine with WPF.
Good to hear
Joined: 24-Mar-2011