a queued layer? so the QL basically receives actions and queue them and processes them on its own pace. The would want a call to like lock to perhaps provide some sync but then you don't flush in doctrine terms until the queue is processed? just an idea.
On Wed, Jun 13, 2012 at 2:50 AM, Xavi Montero <[email protected]>wrote: > 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. > > -- > 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 > -- 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
