Hacker News new | past | comments | ask | show | jobs | submit login

Frameworks exist for that reason. I don't think that means every framework has to be MVC.



Yep. Sometimes it doesn't always make sense. If your models involve pulling data from multiple different, potentially expensive sources or processes, but your user's request only requires knowing a subset of those results or a subset of the model's properties, you may not want to populate every property of the model.

One reason I like Flask over Django: You can do MVC if you want to, but aren't forced to.


Although there are arguments against MVC I don't see how your example is against MVC.


I guess if you're going to argue against MVC, you have to figure out what MVC means first. The original MVC isn't the same as many of the popular MVCs we have today:

https://github.com/ciscoheat/mithril-hx/wiki/Rediscovering-M... https://heim.ifi.uio.no/~trygver/2007/MVC_Originals.pdf


Let's say I have a model called restaurant. Getting restaurant.name, restaurant.type, restaurant.phone are free. Getting restaurant.menu involves spending $X to get it from an paid API. Getting restaurant.photos involves counting against some social network API's rate limits.

Fully populating a restaurant model and sending it along to a view is costly. A user's requested parameters may not have needed the menu, for example.

That's just scratching the surface of the problem. Okay, let's say I create a model called restaurant that's actually a Python class, where menu and photos are fetched only when called. That's fine and dandy, but now, what if the user's request actually needs to render 10 menus, and it so happens that the API cost of getting N menus doesn't linearly scale? For example, what if I could fetch all those menus in 1 API call and spend only $X? Now all of a sudden our abstracted Python class is terrible at minimizing costs, because it will make a separate call for each restaurant object.

Now add in silly time-based rate limits. Photos API allows upto an average of 10 requests/second in a continuously-moving time window of 5 minutes, while menus API allows 50K requests per day, resetting midnight in Pacific time for American restaurants, and another menus API allows 20K requests per day, resetting midnight in Chinese time for restaurants in China. However, you have nearly unlimited requests for the American menus API if the user has used some login method that gives you a user-specific access token instead your application access token. Oh, and the API that provides Chinese menus doesn't support asking for multiple menus in one call. Also, since you have access limits, you choose to not provide menus for less important anonymous user requests, based on some importance criteria, in order to best serve the users that are most likely to stick. You now have a real mess of a framework.

In general, MVC breaks very easily for practical purposes when you're not in charge of the database, and the people owning the data have business motives and arbitrary access restrictions.

If you own all the data and it's in a nice little MySQL database on your own servers, then sure, slap an ORM on it and go MVC as far as you can, I totally agree.


You're complaining about ORMs, not MVC. If you have a use-case for a limited restaurant model just create another class for that use-case, probably with some code sharing. Specialize and all that. Break the abstraction when needed by a real-world requirement, it's not a problem.


How is it the MVC framework's fault that aggregating data from third parties is expensive?

Lazy evaluation will help to some degree, as will caching data locally once you've retrieved it.

Extending your ORM to invoke third party pay-per-view APIs is obviously the wrong way to solve this problem. That does not mean that MVC or ORM are obviously the wrong way to solve this problem.

MVC will help you with the stuff that it is suited to, as will ORM. Neither are suited to optimising usage of expensive pay-per-view APIs. You need to build the API interaction part separately, and arrange for the MVC side of things to work with thst API-using-API.

Off the cuff, why not have a batching task that takes requests from the last fraction of a second and sends them off to each provider? How long can you stretch that fraction of a second without upsetting you customers? Are they willing to wait three seconds? If you get a dozen requests per minute, three seconds might halve your API bills.

As you said, MVC breaks when you do not control the data. So your job is to get the data into a form and place that you control.


That's a lovely explanation of why mediocre ORMs can cause more problems than they solve. And it's well known that Django's ORM is very mediocre, and sadly it's so tightly coupled to the framerwork that you can't just drop in a better one.

...but what does this have to do with MVC? You're entire argument comes down to "sometimes you need to have some smart models to deal with external APIs". Well...yeah?


Are we including Django in MVC now? The term has become completely vague then.

Django's web framework is URL routing plus views, which may use the template engine if they want to. There is also an ORM which is separate from the Web framework and other tools.


Well, from wikipedia:

> Django (/ˈdʒæŋɡoʊ/ jang-goh)[4] is a free and open source web application framework, written in Python, which follows the model–view–controller (MVC) architectural pattern.[5][6]

And realistically it has models, views, and controllers; it's at least as "MVC" as most frameworks we label that, and more than many. If Django isn't MVC, what is?


Smalltalk was. Django's FAQ says that if you want it to fit an acronym, maybe use "MTV" (model, template, view).




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: