Client-side view
Joined: 14-Dec-2003
Walter wrote:
Thanks Frans for your answer, And yes you're right, SP1 for VS.NET 2008 is still in beta, my mistake...
I think everything is released together with SQLServer 2008, which is, if I'm not mistaken, released around october.
I remember having read in some MS paper than the client-side views would be updatable (well then maybe not in version 1) and would be even less restricted than updatable database side views... In which case client side views definitively have an interest by providing an extra O/R mapping at the data access layer with no impact on database. But yes I can understand the saving pain, so don't know they plan on doing it...
I think the effort spend on it is completely wasted: there is no end to how crappy one can create a relational model, and this feature is meant to revive stupid models into proper models without changing the underlying models. But, that's near to impossible unless a huge amount of complexity is introduced.
Their designer supports also absolutely nothing in this area: there's no model refactoring whatsoever, so once you've created a model from a db schema (and that's what you'll do if you have a big relational model), changing the model easily is hard, if not undoable.
By the way just a confirmation : are LlblgenPro entities based on database views updatable? (I have only used them in read-only scenarios so far...)
The updatability relies on if the db supports that. So, if the view consists of one table: it will likely work, if it consists of multiple tables, it won't. In general, I'd add update/insert triggers on the view.
The equivalent of what the EF calls client views are typed lists. They're read only in LLBLGen Pro for the obvious reasons that you'd otherwise always have to fetch non-nullable fields and PK fields and they always have to be present in the resultset, otherwise inserting new rows is impossible.
You probably have been asked already 10 thousands times but: how do you see the future of LlblgenPro with the venue of the Entity Framework? knowing the EF apparently comes with everything an O/R mapper needs + will be integrated in the whole Microsoft suite. And there is this ADO.NET Services comming, based on top of the EF (which in my understanding is not so fenomenal but just is a nice and neat integration of the EF and WCF for providing access to the data in a SOA way, understand that in the future they might also provide this way data services in a hosted way).
Heh 
Yes it's asked a lot. When the EF was presented at first, we were very worried: Pablo did a good job describing what seemed like a supreme O/R solution. But, it's microsoft, so they all are wearing special glasses which block out some essential elements from reality 
.
After a while I realized that what they're trying to build isn't going to work. The main issue is that they try too hard to provide a data-access solution for everything under the sun in such a way that it's too hard to understand. It's also not developed from the point of view of the developer who has to work with it, it's too complex for that. I mean, it took me a while before I understood why entitysets in the EF have separate relationship definitions even though the entity definitions they're the set of have also relationship definitions. And it's my core business! What if a developer who just wants to use it runs into that? Who's going to answer the questions of that developer?
The main issue they have is that a framework that's complex is completely useless without a proper tool or set of tools to manage it and maintain it. Their offering in that area is very weak. They also failed to sell the points of what it makes special compared to all other data-access solutions out there: a developer who wants to manage customer/order entities in his program doesn't give a hoot about the special points of the EF, he just wants to be able to do that. Linq to Sql is then easier to use than the EF, and what does the EF offer in return for the extra complexity? Not much.
But, we're not sitting on our hands waiting for the EF to fail, that would be silly. After all, most big-consultancy firms have a couple of architects on their payroll who will design a new software factory setup around EF. Not that that will help, but clients will love it, initially
So, we thought long and hard and came to the conclusion that we simply should write a new designer which could do model first as well as what the current designer can do, and should support our own framework together with EF, Linq to Sql and NHibernate. Combined with a new code-generation pipeline which will do next-generation code generation (so no more file-oriented templates, but more on that later ), advanced model management (think about refactoring of models, forward mapping / db schema creation / reverse engineering, multi-database mappings in a single project etc.) it will be the de-facto designer to design and model your data-access layer, whatever framework you're using. No more binary files but sourcecontrol friendly files etc. (I can't talk about everything now, the competition reads here too)
We still think our own framework is superior to what MS offers and therefore we'll keep supporting it (and extend it, v3's version will get value type support for example, so you can model 'Address' with a couple of fields and simply define a field as type 'Address'), but we also do realize that people sometimes have to work with other frameworks. To give them the same level of designer quality and code generation help, together with the features we'll bring to these frameworks will make it easy to stick with our designer, even though a competing framework is used.
We have learned from customers that Microsoft has done usage surveys on LLBLGen Pro, how users use it, what's in it etc., so as long as they're targeting us, we'll always be one step ahead .
As the designer is now build with WPF on .net 3.5, we can do a lot more than we were able to in winforms, and we've plenty of ideas to expand in areas where 2.5D (2D + stacked planes) can help a great deal in how users look at their models, get information visualized etc. So v3.0 will be a beginning for a new way of how entity models are designed.
You don't have to worry that it suddenly will use MS' DSL tools and you've to drag/drop all day to get things done . We won't use MS' DSL tools, but our own DSLs, and we aim to be more productive than v2.x is (so projects should be even easier to create / maintain).
I am anyway still addicted to Llblgen but would like to understand where we are heading to and in which scenario to use one or the other technology (Llblgen versus EF) and what one technology would offer more than the other.
Thanks in advance for your time Walter
Our vision for v3 is that you don't have to worry about that: open the designer, model your entity model (either by reverse engineering like v2.x does, or forward modelling using the various tools at your disposal in the designer) and when you're done, you pick the framework you're going to use and with which features.
Hello Frans,
Thank you for this lengthy and very exciting answer So I see that I can keep using my favorite ORM tool with no worries as you are talking of good stuff and ideas for the future
And keep-on the great work !
Kind Regards,
Walter Almeida
