I think you have three options:
- Do it every time, so you have a lot of writes and it is really easy to
implement.
- queue it and flush it at shutdown or at the end of the request. I'm
sure, there is an event.
And the best option is to have queues like Luis said and if you read the
datas you just editied, you write the stuff to the database and read
afterwards. The algorithms to detect wether the write is necessary or
not can be really complex.
It really depends on your needs.
Hope it helps.
Good luck
Fabian
Am 13.06.12 09:50, schrieb Xavi Montero:
> Hello,
>
> We are having _*trouble in deciding where to put the ->flush() call.*_
> Let's see if *you can "inspire"* us, please.
>
> Our application is very big. It currently has about 30 bundles. We have
> 2 separate developer teams: one does frontend (controllers + twigs) and
> another does core (database + services + model, etc).
>
> Frontend is one project (has its own bundles, which do not have any
> doctrine models nor logic nor services, but have twigs, public images
> and css and controllers), and lives in one repository.
> Core is another project (has its own bundles, which offer services,
> model objects, etc, has doctrine objects in their inside and have no
> controllers nor twigs), and lives in another repo.
>
> The goal of this approach is that our product is delivered with
> DIFFERENT FRONTENDS (Core+Frontend1 for the web, Core+Frontend2 for the
> mobiles, Core+Frontend3 for the support-team with a special web to admin
> the normal users). So all "logic" is "in the core" and either one or
> other frontend project is consuming the same services, so an improvement
> in the Core, improves all the deploys without having to re-test every
> piece of frontend.
>
> So... we are trying that the controllers NEVER access the doctrine
> objects, but acces a "modelling layer", so if ever the persistance layer
> changes, the controllers and twigs (ie: all the frontend) remains
> without a single change so we only have to re-test the core but not the
> frontend.
>
> We are trying to make a MODEL in such a way that all access to DB in
> "encapsulated" so the controllers do NOT access the doctrine but to
> "services" that in turn use doctrine. Suppose we treat the objects
> "cars" and "people", then a controller can access a "cars_manager"
> service or a "people_manager" service from which to do ALL necessary
> operations (create objects, retrieve them, etc).
>
> _*Where would you put the flush call?*_
>
> Example (in *pseudo-code,* to make it simpler to read):
>
> controller AjaxJsonAddDriverToCar( $CarId, $DriverId )
> {
> try
> {
> $Cars = getService( "core.cars_manager" );
> $Car = $Cars->getCarById( $CarId );
> $Car->addDriver( $DriverId );
> $Result = JSON_OK;
> }
> catch
> {
> $Result = JSON_FAIL;
> }
>
> return $Result;
> }
>
> Provided that the controller does NOT know how the core is
> implemented... it should NOT get the doctrine and perform a ->flush() on
> it.
>
> Inspiration is welcome.
> Thanks.
>
--
Fabian Blechschmidt
Crailsheimer Str. 10
D - 12247 Berlin
Tel: +49 (0) 30 419 932 55
Handy: +49 (0)176 666 55 256
E-Mail: [email protected]
--
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 developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/symfony-devs?hl=en
