I appreciate this analysis. Personally, I think most of us would avoid complicating things to slightly facilitate an improbable transition to another framework.

I have recently taken a strong turn towards stringent interface contracting and making everything as abstract and interchangeable as possible.

A few things I've learned along the way:

• It's useful to decide, very early on, what rigid dependencies you're willing to tolerate. For instance, most of my applications are written to have a requirement for Laravel's core, but everything else is built to interfaces. Some of my projects outright delete the Facades for Auth. Others might even want to be Framework-agnostic. Pick one, commit to it, and make sure it's written in stone.
• It always looks like there's more scaffolding when you start the classes (new service providers, new classes, more namespaces, more interfaces, etc) but that's a one-time deal. Much of this is easily copy-pasted between different pieces of code.
• I started off by feeling that the verbose code was against the whole idea of using a framework, but then I realized that the bulk of the work is still handled by Laravel and its minions; most of the code I write is just verbose because that's how PHP demands namespacing, class declarations etc to work.
• Testability and swappability are the key considerations. It's easy to get pushed into the "I'll probably never have to switch away from [x], screw IoC/interfaces" mindset, so I think of it differently; building code in this manner allows me to have multiple functioning implementations of each sub-system. At first glance it might make sense for everything to be tightly coupled, but when the day comes (more on this in a second) that you need to replace a segment of code, sure you could just start wiping out your existing class and writing your new logic on top of it... Or you could code to the interface in a new implementation, and just swap over an IoC container binding.

That last point is key for me: if a project I'm working on is serious enough for "when the day comes" scenarios (e.g. if my messaging system gets too big, might I be asked to move to a separate dedicated messaging API on a separate server, keep data on redis/memcache, use a different Mongo DB instead of the main MySQL, etc), then I will abstract the hell out of my project.

It might cost a small amount of time to build the additional scaffolding, but in a large project, decoupling code is way more time-intensive and error-prone. If you foresee this happening in the future, make sure you're ready for it!

I use some of the packages I write on other frameworks than Laravel. For simple projects we usually use Silex with Laravel and Symphony for the big application work - so for my situation having abstraction built in from the set go is quite important - but then its also built into the scaffolding tool-chain I built to make such extra work moot.

TD:LR; if you don't expect to have to use the code you write for any other framework, then there is no harm is tightly coupling it to the framework you use - just keep in mind that code needing testing has enough abstraction in place to allow it.

Lean software development, do only what it takes to get the business requirements satisfied with competency. Write good OOP and test your code so that any refactoring (will be needed with like every new feature ever) will be painless.

Decisions like decoupling from the framework aren't real decisions unless you have that as a business requirement. Instead, focus on just writing good OOP code. You'll automatically have a solution that's abstract enough for the moment and easy enough to refactor.

I recommend Uncle Bob's video series on fundamentals on http://cleancoders.com

Additionally, Sandi Metz has a book called Practical Object-Oriented Design with Ruby that is extremely relavent to a PHP developer.

ShawnMcCool said: Instead, focus on just writing good OOP code. You'll automatically have a solution that's abstract enough for the moment and easy enough to refactor.

So, I'm curious. In this actual example would doing it as way (1) from above (tightly coupled to Laravel) be considered writing good OOP code?

Hi Guys,

I know this is quite an old post now but I thought I'd share my way of handling events in a DDD fashion.

As Shawn said, the decision to decouple code from a framework might be a business requirement, however, more than not this is not the case.

My way of working is to always decouple the code from the framework, but this is not to just satisfy the possible requirement of a new framework but for satisfying a lot more principles such as the SRP. Furthermore, it makes perfect sense to invest 5 minutes one each provider by decoupling them from their actual implementation using an interface. This will yield to a lot of benefits, mainly extending of your software but also to have everything organised the same way.

So, I handle events this way (but I also handle everything this way from Auth, Validation, Payment providers etc..)

Let's say I have an eCommerce application, which allows users to register and on registration a User event listener needs to get a cookie with the Cart id to link the cart to the new user.

First of all the events provider itself:

Ecommerce/Providers/EventDispatcher: EventDispatcherInterface (contract) LaravelEventDispatcher (implementation) EventDispatcherServiceProvider (binding) AbstractEvent (just an abstract class which has the above dependency) AbstractEventListener (just an abstract class which has the above dependency)

Then the User events are grouped into one class - I like this approach so that I have a list of events for each resource(entity etc..)

Ecommerce/Events/UserEvents (extends AbstractEvent ) - this class only fires events.

Then the Cart needs to listen to the above event: Ecommerce/Events/Cart/CartEventListeners (extends AbstractEventListener ) - this class only listens to events and calls the handler which is normally a separate service.

If anyone would like to see the code for these just let me know and I'll share a Gist or something similar.

In reality this takes only a few minutes more to setup but you save several minutes while working because you know exactly where things are. Not to mention how easy it is to test it and extend on it.

My opinion is that working this way makes me feel a lot more confident when myn projects are handed over to larger firms and support companies. I know for a fact that good devs can understand my approach and not so good devs will love learning from it :)

@keithmifsud

Do you consequently work with loCs?

philippzentner said:

@keithmifsud

Do you consequently work with loCs?

@philippzentner I don't understand the question in relation to the thread?

I guess you should try using "Ahsay backup software" as this software can surely resolve your problem and most important i can give backup to large files as well. So give it a try.