I will concur with Richter here. It is far better maintenance-wise to
keep all your application logic in the app and not distribute that
around into the database. The only time a view is of use is when an
outside batch-script or cron job might use it as that is not directly
related to your application logic, and even then I'd not rush into that.
Imagine a year from now, another developer needs to take over
maintaining the application. If he needs to start looking outside the
application for "code" it will make his job that much harder. Thats just
one example. Debugging becomes a bit tougher too with database-located
logic as you need to determine if its DB or app.
On 26/02/2011 19:27, Richtermeister wrote:
Hi Himanshu,
this seems overly complicated. Since you're getting the same fields
from the database regardless of which user is logged in, you should be
fine using the same class to access those fields. The model shouldn't
change depending on which user uses it, only different data should be
accessed. This is simple enough to do:
ProperyQuery::create() -> filterByOwnerId(1) - find(); //Propel
example
Secondly, views give no performance boost, because underneath it pre-
executes the query that defines the view every time you access it, so
you may not have to write the WHERE clause, but it's still being
executed. In symfony land, by using ORMs, we derive similar
flexibility just in code. For example, if you find it too tedious to
filter the Property entity for the current user every time you access
it, just add a getPropertyQuery() method to your session user (myUser)
so that does this filtering for you in one spot.
The reason this is the recommended approach is because you're not
spreading your business logic across multiple layers (application,
storage, etc). It's all in one place - the application. Imagine you
want to switch to a database that doesn't support views, then you'd
have a big problem. Using Propel/Doctrine logic instead - no problem.
Of course you're free to do whatever you like, this is just my
opinion. :)
Daniel
On Feb 26, 5:11 am, himanshu<hisupa...@yahoo.com> wrote:
Hi, I want to extend base classes dynamically.
Following explains my requirements.
I have a table 'Property'.
Columns are 'property_id', 'owner_id', 'name' and many more.
So default there will be BaseProperty class, Property class extending
BaseProperty class.
I want to use mysql views.
views will be ctreated like following:
vwProperty1 : SELECT * FROM Property WHERE owner_id = 1
vwProperty2 : SELECT * FROM Property WHERE owner_id = 2
I want to extend BaseVwProperty1, BaseVwProperty2 class dynamically.
Based on login of Owner, I want either
class Property extends BaseVwProperty1
or
class Property extends BaseVwProperty2
And not following, which is default
class Property extends BaseProperty.
The usage of views can give performance boost and many thing you need not set
every time, it eliminates lot of physical "where" conditions. This is an example
and can be used in complex conditions.
Any help will be appreciated. A solution or a suggestion of using any design
pattern to achieve above.
Himanshu
--
If you want to report a vulnerability issue on symfony, please send it to
security at symfony-project.com
You received this message because you are subscribed to the Google
Groups "symfony users" group.
To post to this group, send email to symfony-users@googlegroups.com
To unsubscribe from this group, send email to
symfony-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/symfony-users?hl=en
