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:
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?
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 :)
Do you consequently work with loCs?
Do you consequently work with loCs?
@philippzentner I don't understand the question in relation to the thread?
Sign in to participate in this thread!
We'd like to thank these amazing companies for supporting us