A View in Database Terms is a predefined, "constant" query generating something that behaves nearly identical to a table.

In contrast what Entity Developer calls a "view" is a query that is hard-coded into the Client side application code, sent to the database repeatingly and interpreted from scratch each time the applications accesses the database using that view.

This brings a few drawbacks:
1) A view query may be quite complex. A Database Engine might keep track of executions of that query and optimize it. This might be easier or even possible on views as the view is a known, fixed query.

2) On some database Systems (e.g. Oracle) a view can be "flagged" as "materialized". With that, the result of the view query is stored in the database and the dbms makes sure changes of the underlying tables are recognized and Trigger the necessary updates of the view. For Views that are read often and where the underlying tables are written only occasionally this is a good way to improve Performance without the application code to handle synchronization issues.

3) Privileges: Many databases allow view privileges to differ from the Access rights a user might have on the base tables. Thus a dba might be able to restrict Access to certain tables or columns - or even calculated columns to prevent unauthorized access on database Level. A complete model would allow to generate these views (using a privileged database account) and to use them using a restricted account later, where that might not have the access privilege for the underlying table.

See this discussion for reference as well: http://forums.devart.com/viewtopic.php?f=1&t=30988