My question is simple. Soon I found this is an old issue, so I searched and read a relevant post to understand better.
In “Meteor way”, is it not so meaningful to embrace MVC way in framework level?
(by easy optional choice, and providing some good guidelines)
Meteor seems like using template modular approach(This is just my expression, I’m not sure if this is right) - template and it’s js,
and each js is acting like controller in template level.
You know controllers, how about employing controllers in the conceptual level division. (i.e. PersonController, CarController)
I know there are answers like “Meteor doesn’t force you into one design concept.” or "it’s up to you."
But is the reconciliation between meteor way and MVC way often meaningless or hard to do? (I’m saying framework level provision.)
Why should we take it for granted to forget about the benefits of MVC so easily?
As an opinionated framework, why is it not acceptable to embrace MVC?; Even at least optional way.
(Sorry to use too many “why”.)
FYI, a relevant post and comments:
Meteor follows the MV* pattern with self updating views that “react” to model changes.
It’s up to you to plug in controllers or view models, or whatever middleware you want to use to interact with the models.
Meteor is MV* What does that mean?
Model - Meteor provides a mongodb based model for use. It’s a reactively updated model which has some nice workflow elements built right in.
View - Meteor provides us a view in the Spacebars/Blaze template system. It’s more of the MVC style view but it does have it’s own events system.
(*) - Meteor waits for you to tack on the rest. It doesn’t provide out of the box either consistent view model bindings or controller based routing.
So it’s up to you to put in your code for the *. You can use Iron:router or flow router to accomplish most of an MVC pattern.
Meteor really is MV* because it provides the M and the V but not the *.
Meteor doesn’t force you into one design concept.
Meteor doesn’t implement the whole of any pattern but puts you in a place where the last piece is easy enough to implement.
It’s easier to think of Meteor in terms of Meteor than in terms of design patterns that other frameworks have used. MDG is very big on not telling you HOW to use their framework and as a result it leaves a lot open.
I really don’t know why we have a compulsion to classify everything.
When I am working in RoR, the MVC pattern is quite clear. It’s part of the methodology of the framework.