What are the advantages\disadvantages of a View stored in a database versus a Dynamic Query?

I am new to .Net and ES and I am still trying to wrap my head around a lot of basic design issues.  When I create my edit forms, I like to present the user with a read-only grid listing the available records.  When they select the record that they want to edit, I like to give them a modal dialog where I can control their editing experience (and also force then to save\cancel on a record by record basis).  I want to bind the grid to a view\query so that I can more easily alow filtering\sorting on related fields.  Which should I use ... a stored view or a dynamic query?

Yes, that is exactly what I am trying to do.  Actually, I use a single form with the grid on one page of a pageframe and the editing on one or more other pages, but functionally it is the same as using a modal form.  It is reassuring to know that my approach makes sense to someone else.

 What do you think?  Does it matter whether I use ES Dynamic Query and generate my grid view on the fly OR should I use a view that is predefined and stored right in the database.

Our design philosophies seem pretty consistent. Up until about six months ago, I worked pretty much as Martin has described. Views for the read-only grids, LoadByPrimaryKey in a modal Add/Edit dialog, Save() on OK. But, since the addition of Joins in the December ES2007 release, I have taken a different approach in newer projects.

The read-only grids and modal dialogs are still there, but rather than having to open SQL Server Management Studio, putting on my SQL syntax thinking cap, and designing a View, I add methods in the custom classes that use EntitySpaces DynamicQuery to accomplish the same thing. Now, all my code is written in one language (C# in my case), and can be maintained within Visual Studio. When the database schema inevitably changes, I get compile errors in my business class method after re-generating, rather than runtime errors, if I forget to change one of the Views.

As Martin says... not going to work for every project... just some food for thought.

I use the same approach as David and the result is fantastic.

Even better with joins. Without joins we were kind of limit. but now, not anymore.

Mantain views is much pain than mantain C# code.

The great advantage is what david said:

When the database changes, you get compile errors in you class, rather than runtime errors.

You don't have inespectable errors because you accidentaly forget to change the view.

Wow!  I like the sound of keeping everything in C#, especially because I may have to support different back ends.  I really love what ES is doing for me.  I am going to be able to keep all of my logic in one spot.

Are there any good examples of how to set up the methods in a custom class to achieve all of this?  Are there any sample applications doing read-only grids with modal edit?

Well, not too complicated.

Choose an EntityCollection where the Custom Load method (your view in this scenario) will be.

Create as many custom methods as you wanted that load the object collection using dynamic query, joins, filters, etc.

Simple use these method in your form.

I agree.  Adding a custom method is not too complicated. 

But...

Putting it all together to create a well behaved read-only grid with a modal add\edit forcing record by record save\cancel is not a trivial exercise.  Especially for someone like me who is still climbing the learning curve.  Does anyone have an example app that might help?

All I have to say is database independence is awesome! I don't use views and I don't use stored procedures.

 I love this link:

http://www.tonymarston.net/php-mysql/stored-procedures-are-evil.html

With ES, views and stored procedures are both EVIL - IMO because of the database indepenedence as well as many points noted in the link above.

There area a few exceptions, but hey - just one guy's opinion.