In a recent thread I posted a problem I faced with typedLists that I did not face with typedViews. This prompted to start rationalizing why I would go the typedList route if I can do the same by creating a view (which are standard SQL language objects that can be created in all the SQL engines supported by LLBL) and then creating a typedView based on it.

I managed to come up with only 2 reasons: 1- If the DB admin deny me access to the DB to create my own views or objects

2- If I make an architectural decision that views are business logic that should reside in the BL and not in the DB.

Now I know point 1 is purely political and as such is out of discussion but I wanted to probe what everyone thought of point 2 and if there are any other reasons that I should favor typedLists over typedViews

3) A typed view's definition is static, while a typed list can be built dynamically from the appropriate tables, and relations. This of course can increase both flexibility and complexity.

arschr wrote:

3) A typed view's definition is static, while a typed list can be built dynamically from the appropriate tables, and relations. This of course can increase both flexibility and complexity.

this is true for DynamicLists which are typedLists build in code. TypedLists build in LLBL's designer are very similar in concept to SQL views because they do become static data objects (or more accurate BL objects) that get generated in the DAL and treated as a normal DB object.

this is true for DynamicLists which are typedLists build in code.

O.k. I didn't know me building the code vs the designer/generator caused them to have a sprecial name.

I struggle with question myself, as I've tended in the past to see the database schema as the primary definition of business rules, and that all other business rules "hang off the data model" in the words of a friend of mine. So according to that perspective I'd have said that SQL views are the correct way to implement this.

But my views on this have changed in the past few years, and I'd now lean towards using something constructed in LLBLGen. Why? Partly because I'm fed up with the politics that govern how the database changes, and partly because I just like the separation of having business logic that isn't purely structural assertions in a separate layer.

Don't forget too that in the next version of llblgen pro (2.1) there will also be an additional tool to add to the toolbox - composite entities.

omar wrote:

2- If I make an architectural decision that views are business logic that should reside in the BL and not in the DB.

Most of the time, the views i need are tied to the presentation logic (I am still not sure if that's the same as business logic). Changes to the UI layer are relatively frequent, but i do not want to have to update the db every time a change in the UI is needed. Deploying only application code is much easier.

In short: The driving force to use typed list is to keep the database as stable as possible.

wvnoort wrote:

omar wrote:

2- If I make an architectural decision that views are business logic that should reside in the BL and not in the DB.

Most of the time, the views i need are tied to the presentation logic (I am still not sure if that's the same as business logic). Changes to the UI layer are relatively frequent, but i do not want to have to update the db every time a change in the UI is needed. Deploying only application code is much easier.

In short: The driving force to use typed list is to keep the database as stable as possible.

I'm saying pretty much the same thing, but in a bit of a different way: implement changes as far away from the database, and as close to the user as possible (without having to duplicate the change). This way, the change will have hopefully minimal side effects on code that you did not intend to be affected (other code possibly written against your view).

Thank you guys for sharing. I was worried that maybe I was missing something. I tend to distinguish between projects on the basis of size and complexity. Sometimes, when building small or simple applications, the developer has full control over the database and in this perspective it becomes really hard to clearly say why I should go for one against the other. For larger and more complex systems, I rank maintainability very high and as such I would prefer to build my views in LLBL.

One feature I am really looking forward in the upcoming LLBL v2. is composite entities. The would allow me to build view-like functionality (with business object behavior) for my entities and that really opens up a lot of possibilities.

What do the LLBLGen support team think about this i.e. whether typed views or typed lists should be created.

I would have thought for existing systems which you use LLBLGen on the answer is different because you would like to re use existing views as TypedViews rather than create additional work by creating TypedLists through the designer.

However if you don't have any typed views in the system from the start then is there any point in creating database views and then generating and using corresponding typed views in LLBLGen

Thoughts please

Advantages of database Views: 1- Views can use fields from tables not mapped to LLBLGen Entities. 2- Views can be handy if the resultset is based on a complex query.

Otherwise I use TypedLists.

Another one for our best practise LLBLGen document

One advantage of TypedLists is with the upcoming SQL Server 2005 Compact Edition Driver. This Database doesn't support Views and with TypedLists you can make your application compatible with this Embedded Database.

Another big advantage of database views is that you can access them from other applications, including SQL Server Management Studio.