This is a request for comments / feedback.

In v3, the designer is rewritten from the ground up with re-using parts of the code in v2.x's designer. One of the things we're looking at currently is if we should keep supporting TypedView elements.

Before you might think: "Yes, keep them, I use them!", we're not here to make your life miserable , so please read the proposal, and if you think typed views should stay, please describe why. If you think our proposal is a good idea, you can simply say "good idea" or similar, so we have a bit of a view what our customers think. Thanks!

Proposal

In the converter of v1.x/2.x projects to v3.x projects, we'll convert TypedView elements to an entity and map that entity onto the view and at the same time add a Typedlist with that entity. This gives the situation that you can use almost the same logic in your code to fetch the data (as a TypedList is also a typed datatable), however there might be some minor changes here and there with respect to filtering.

Why do they need to go?

When LLBLGen Pro v1.0.2003.1 was released, we didn't have the ability to map an entity onto a view (as views are read-only). However later this ability was added, so TypedView's became a bit of a weird element. With the new designer, we want to clean up things which aren't used anymore or became obsolete, and one of the candidates to not build into v3 is typedviews as they're actually redundant. Although we can think of the consequences, we don't know what the impact of these consequences can be for you when you upgrade to v3. If this impact is huge, we of course can't nor wont cut them.

Again, don't panic, we haven't axed them yet.

With respect to mapping the typed view to an entity. Is there an issue with identifying the/a primary key for the entity? Or does it not matter as long as you don't use the the entity for straight entity things?

If details are worked out, you proposal are o.k. with me.

I'm not too happy with the way typed views work anyway now, so get rid of it

Do you think we are going to have the possibility to map existing entities to a view (=entities already mapped to a table)?

Thanks!

Wiebe

I have almost exclusively mapped database views to entities since our DBA only provides Oracle synonyms to us. After mapping, I manually select the PK's and then create the relationships. In essence, we treat the views as straight entities with no problem.

In my opinion, therefore, there really is no need for a TypedView since you can easily define a read-only entity that does basically the same thing.

arschr wrote:

With respect to mapping the typed view to an entity. Is there an issue with identifying the/a primary key for the entity? Or does it not matter as long as you don't use the the entity for straight entity things?

If details are worked out, you proposal are o.k. with me.

The entity itself doesn't have a PK, as that's not determinable, though in theory you could go in the editor and mark fields as the PK.

As we've grouping in the designer now (1 level deep), we could group these entities in their own group so they're separated from the rest.

Otis wrote:

arschr wrote:

With respect to mapping the typed view to an entity. Is there an issue with identifying the/a primary key for the entity? Or does it not matter as long as you don't use the the entity for straight entity things?

If details are worked out, you proposal are o.k. with me.

The entity itself doesn't have a PK, as that's not determinable, though in theory you could go in the editor and mark fields as the PK.

As we've grouping in the designer now (1 level deep), we could group these entities in their own group so they're separated from the rest.

In our particular situation, we are actually treating views AS entities since the DBA wants more fine grained control on his end. Separating them therefore would change semantics in our particular case.

wtijsma wrote:

Do you think we are going to have the possibility to map existing entities to a view (=entities already mapped to a table)?

An entity can have 1 target, so you can map it to a table or a view (like the case now). It became really hard to map an entity to multiple targets in the forward mapping scenario (create new entity and then map it onto existing or new targets) so we postponed that particular scenario (which is really an edge case) for the first update after 3.0.

You can change the target of an entity in the editor if you want. See screenshot (don't mind the obvious length bug in the field, these are taken care of before release ).

The Customer entity here is the only entity with a mapping. Obviously this project is invalid (as only valid projects are allowed for code generation etc.), though the validator code has not yet been written (is designed though).

Seth wrote:

Otis wrote:

arschr wrote:

With respect to mapping the typed view to an entity. Is there an issue with identifying the/a primary key for the entity? Or does it not matter as long as you don't use the the entity for straight entity things?

If details are worked out, you proposal are o.k. with me.

The entity itself doesn't have a PK, as that's not determinable, though in theory you could go in the editor and mark fields as the PK.

As we've grouping in the designer now (1 level deep), we could group these entities in their own group so they're separated from the rest.

In our particular situation, we are actually treating views AS entities since the DBA wants more fine grained control on his end. Separating them therefore would change semantics in our particular case.

Separation isn't something like 'it's in a different project'. What I meant was more that they're grouped together so you can easily recognize them. (which should be optional I think).

The main point is: do you use TypedView's at the moment? (you use entities mapped on views, so it's not affecting you, you will be able to use the entities like you're doing it now: map them onto views). If you're using typedview's, should they stay in v3, or do you want to settle for the workaround, which is: having an entity mapped onto the view and a typedlist with that entity as only entity (which thus results in the same typed datatable).

I use TypedViews.

And if they are removed in v.3 in favor of an Entity and then a TypedList to migrate old projects, wouldn't this be a waste of code to get an Entity that I will not use.

I would have suggested, to have the ability to have:

1- An Entity mapped to a table or view,

2- A TypedDataTable mapped to a table or view (incase I have a table that I want to treat as a view).I'd rather have this than an entity that I wouldn't use and then a typedList.

3- A TypedList.

Walaa wrote:

I use TypedViews.

And if they are removed in v.3 in favor of an Entity and then a TypedList to migrate old projects, wouldn't this be a waste of code to get an Entity that I will not use.

I would have suggested, to have the ability to have:

1- An Entity mapped to a table or view,

2- A TypedDataTable mapped to a table or view (incase I have a table that I want to treat as a view).I'd rather have this than an entity that I wouldn't use and then a typedList.

3- A TypedList.

Good stuff. It's indeed more or less a waste of code, as the entity itself (and in selfservicing also its collection class etc.) isn't really used in entity scenario's I think.

So instead of getting rid of TypedView's you propose to make the feature bigger, like having a simple straight forward readonly datatable on table OR view... interesting. Never thought in that direction.

Could you elaborate a bit about the user-scenario's in which you'd use these typed datatables? E.g. would it be to avoid having to create a typed list from a single entity ? (which is in effect the same thing)

Could you elaborate a bit about the user-scenario's in which you'd use these typed datatables? E.g. would it be to avoid having to create a typed list from a single entity ? (which is in effect the same thing)

Yes.

Sometimes you get to have tables to use in a light way, like look-ups. eg.: a currency Lookup from

Another example is: when you build an application on a database that other systems are using. So you might need to read from a table which is maintained by another system. So my application will never insert or update or delete from this table, just read.

my senario for using typedViews are:

1- UI search screens used to fetch data from a a complex heirarchy. I would build a view to be used by the search logic and let the BL fetch the complete tree based on the passed row(s) from the UI's typedView

2- VS Designer support seems to be always much better for Datatables. Thats why I would always opt for typedViews when going for client-reporting. I gain design-time report-view which is either NOT possible or very difficult with entityCollections

The first point ofcourse can be worked-around using the same architecture you are proposing now. I could map the SQL view on an entity for the UI to use and then let the BL take care of handling this false entity in the proper way.

To be honest, I don't see myself missing them very much as what I would have preferred was for the designer to automate the generation of DTO classes (POCO classes designed to map to one or more entities to be used as light dataTransfer objects between the BL and its consumers).

Personally I'm not at all keen on datasets/datatables. What I'd much rather see is the ability to generate read-only POCOs + the appropriate projection code in those situations where I need a read-only table/view.

Losing typed-views is no great loss IMO.

Jeremy

Ive been using LLBLGen since 2004. Keep up the great work.

In my RDBMS Systems I use indexed views to partition data and normal views to build "human usable" data structures (i.e. reporting, etc). So I still need to get data from views in my RDBMS. My data access code doesnt care where that data comes from, table, view, stored proc, etc.

When I write my data access code, it has always been a little wierd to have DataTables mixed in with EntityCollection and Entity.

If typed views went away and the database entities that were returned were real entities, and not subclassed data tables / data rows, my codebase would be more consistent.

At the end of the day the consumers of my data access class does not care where the data came from.

That being said, we need a way to move our existing codebase forward with minimal pain. You have always done a good job of this so I am not worried.

I do not beleive that much would be lost by removing typed views from the designer.

Otis, I have created views when the logic is too complex to build in LLBLGen. Many times it is for reporting. Also, sometimes I have views that are sort of a hierarchy - so they are made from other views, etc.

Anyway, when I have a view, I ALWAYS use a TypedView to represent that view. I have never mapped an entity to a view.

Can you help explain the functional and performant differences between the two options?

Typed View 1) TypedView makes me have to use datatable, etc - I cannot use standard llblgen collections. 2) Extending TypedView is very different and I have to use other extension points, etc.

Entity mapped on View 1) Get regular llblgen collections and features. 2) Extending is the same. 3) Save() just fails or not generated or something?

So, what would I lose exactly?

Also, as far as the conversion goes - once you map an entity onto a view, Why would you then have to make a typed list? Just so it is easier? I think personally, I would rather just do the view map and then fix the code - should be trivial changes?

Finally, what exactly am I going to be gaining with V3?
I have heard very little about it and just wanted to know how my development was going to be impacted for the positive?
When can we see a tenative feature list? When any betas or anything be available (assuming there are some great benefits in new version)?

Thanks all for replying!

Considering the feedback, we'll keep typedviews and will extend them to also be able to map them onto a table directly, like Walaa's idea.

WayneBrantley wrote:

Finally, what exactly am I going to be gaining with V3?
I have heard very little about it and just wanted to know how my development was going to be impacted for the positive?
When can we see a tenative feature list? When any betas or anything be available (assuming there are some great benefits in new version)?

the biggest gain you'll get is that you can manage your database model from within llblgen pro: it will allow you to define the entities first, then generate the database schemas from it and also maintain those (so after a while, things change, you add a field to an entity, remove one etc. and you generate a change script for the db to reflect these changes).

If you already work from the db and you don't change that, you'll have the advantage to use value types (so grouped fields into a single type, like Address) and use that as a type of a field, group elements in groups (1 level), a xml project file instead of a bin file, much faster designer (adding 1000 entities in less than 5 seconds), multiple inheritance types in a single hierarchy, and the ability to use entity framework, nhibernate, linq to sql if you got bored of our own framework .

Also much more nice features I won't talk about now.

It will take a while before it will be released, but it will be worth the wait. We want to make a huge step forward for the years to come and as we think our current v2.6 offering is pretty solid, it won't hurt us that much if we'll take a couple more months to make things great.

To all: thanks again for participating. We'll start more of these threads in the coming months if we need feedback from our customers on a design decision.

Otis wrote:

The main point is: do you use TypedView's at the moment?

We are also make heavy use of TypedViews in a large project - we use them mainly for fetching data in read-only grids (paged/sorted).

The main reason for using them was that, when using entity collections or typed lists, it was not possible to define complex computed fields/columns - so we were forced to use db. views for this. Anyway, most of these views can't be automatically mapped on a single entity (maybe on several), so an entity mapped onto a view is not an option on this case. Also, in many places we assume the a row in a typed view is a strongly-typed wrapper over a ADO.NET DataRow.

Lack of support for typed views in 3.0 would mean a very hard migration effort, so please keep typed views if possible ..

Typed views are there in v3, in fact, we increased support for them In v3, you can also map a typed view to a table and to a stored procedure resultset , and not map all the fields in the mapped target to an element in the typed view.