从头开始创建Moduler应用程序

Question

I hope someone can guide me a bit, in the company I work they want me to build a super modular app,meaning that in the core is very simple and streamlined system for which there are modules added per needs. So most important thing is to figure out the CORE module, that is nicely extendable with all sorts of modules.

I was thinking of creating a MVC php framework with modular usage. But when it comes to how to add the future modules I get blocked, I am a magento developer and I cannot stear away of how the modules are done so I just dont want to copy.

Any suggestions or guidelines I should follow, thanks

Answer 1

I would use (or am working on) what i call "Emvc"( or Events and mini MVC).

With events, basically you can make an event system, that you use as a mediator (that's a pattern) you talk between modals using the mediator. Then the mini MVC is basically on a plugin by plugin basis. So each plugin implements its own MVC.

Some Examples.

User system. TThe problem with MVC. is you put that system in

  app/contolers/user
  app/models/user
  app/view/user ..

Just for example, now when you want to add remove it its very difficult to separate that from the MVC.

With Emvc you would structure it this way.

 app/plugins/user/contoller
 app/plugins/user/models
 app/plugins/user/views

Then you would register it to certain events, like the request events for the pages it listens too. I would also listen to things like getCurrentUser etc. This seems simple. but what happens is you do something like this

  //users bootstrap
 $Mediator->listen('GetCurrentUser')

 //called from some other plugin
 $Mediator->trigger('GetCurrentUser', $event)

Then the Mediator checks if it has any listeners for that event, and if so hands them the even object. The listener then returns a user and modified event object. And as long as you have proper interfaces. What this does is the caller no longer cares where the user came from. It could come from class OldUserSystem or class NewUserSystem because you have a separation layer.

In a Normal MVC you would have to call the user system directly, calling the model.

  $Users = new User();
  $CurrentUser = $Users->getCurrentUser();

Now if you replace class User with something else your stuck using the same Name same method calls, or your rewriting your code. The implementation of the listener is hidden from view. Maybe the user system calls this method foobar , sounds ridiculous but with events you could make that triggered by that event.

Also if an event is not handled then you can tell this in the caller and act appropriately because maybe there is no User system at all. It's also up to each User system to render it's own pages, do its own routing etc. etc..

Another good example is billing.

Someone buys something on your site, do you use Stripe, Paypal, Athorize dot net. With an event system. You just issue a event to doPayment send the information as part of the event object. And any payment system that is listing can handle it. You can change payment system without ever touching anything up to the even being handled.

etc...

I will tell you it's not a trivial thing to build. It's a matter of identifing the responsibility of each "Plugin" and having it do only those things, and in a way that is invisible to other "Plugins".