1

i got a little bit confused about decoupling, separating of concerns, the framework (Symfony2) and my business model. Let me explain :)

In modern web based projects we're supposed to have a thin controller. This seems to be best practice nowadays. Also it seems to be best practice to decouple the framework and the business model. And to do separation of concerns. I'm fine with all of that. Using events/event dispatching works like a charme to solve these concerns.

But now i have a task where i need to do the following things:

  • read a cookie
  • save some data to the database based on the contents of the cookie
  • delete the cookie

First my understanding of working with cookies in Symfony2:

  • I read the cookie using the request object
  • I manipulate the cookie using the response object
  • I should avoid using \setCookie directly

And that's the point where i got confused. Because:

  • I would assume that all of the three steps are part of my "task" i need to perform. So it would make sense to do all of the stuff in the same class/piece of business model.

  • I want to avoid mixing up my business model and third party components (like the request/response) as much as possible.

Now i have two options - But both of them are feeling wrong in some way:

  1. Being strict on decoupling framework and business model - Reading/writing the cookie will be left in the controller, since framework components are involved. The persisting is done in the business model. - BUT: Not all the code belonging to the task are in one place now.

  2. I also could have all of the code necessary to perform the task in one place. But then i would need to make the request and the response available within my service, which i try to avoid.

How do you guys handle this kind of issues ?

Thanks, Stephan

stijink
  • 227
  • 1
  • 2
  • 11

2 Answers2

1

I suppose that you have to make a choice: if you're trying to avoid injection of the request into a service you have to manipulate it into the controller directly.

Of course you could use a private controller that you can call from an arbitrary action and where you can store all the code: that way you could follow the DRY methodology that is always a good practice and you'll avoid injection.

In my vision of symfony however, I would use a service with injection keeping controllers small and not heavy. In that service you could store all business logic related to controller's object manipulation.

This answer, however, could vary from devel to devel so it's hard to find the right methodology

DonCallisto
  • 29,419
  • 9
  • 72
  • 100
0

Regarding decoupling from the framework, I wrote a blog post about that here http://thesolidphp.com/decoupling-application-from-framework/

You could separate the cookie handling by creating your own class that will use the Symfony cookie manager. That class should implement an interface like CookieStorage. Your domain objects will only depend on that interface. A concrete implementation could be SymfonyCookieStorage, that will call the Symfony cookie handling objects. Now your business objects are separated from the Symfony cookie manager.

It's the same concept I wrote about in the blog post. That way you could decouple basically everything and keep you objects unaware they are using Symfony.

thesolidphp
  • 161
  • 3