Tag Info

Hot answers tagged

28

The model is not limited to interaction with the database, the model is responsible for getting and manipulating data. So, to your view and controller, it should make no difference, if the data comes from a database or from a webservice or is even totally random, therefore you should do it in model. MVC is a presentation pattern, that only separates the ...


17

Because making the GUI lib thread safe is a massive headache and a bottleneck. Control flow in GUIs often goes in 2 directions from the event queue to root window to the gui widgets and from the application code to the widget propagated up to the root window. Devising a locking strategy that isn't lock the root window (will cause a lot of contention) is ...


16

Toward the end of his failed dream essay, Graham Hamilton (a major Java architect) mentions if developers "are to preserve the equivalence with an event queue model, they will need to follow various non-obvious rules," and having a visible and explicit event queue model "seems to help people to more reliably follow the model and thus construct GUI programs ...


13

Threadedness (in a shared memory model) is a property that tends to defy abstraction efforts. A simple example is a Set-type: while Contains(..) and Add(...) and Update(...) is a perfectly valid API in a single threaded scenario, the multi-threaded scenario needs a AddOrUpdate. The same thing applies to the UI - if you want to display a list of items with a ...


12

There's a common (intentional?) misunderstanding about what M, V and C are. Not about the roles they take, but what are they. In the original, desktop GUI definition of MVC, they were modules. Typically an application had several of them, sometimes working in triplets, sometimes having a variety of views and models that a few controllers could mix and ...


9

I read a really good blog some time ago which discuss this issue (mentioned by Karl Bielefeldt), what it basically says is that it is very dangerous to try and make the UI kit thread safe, as it introduces possible deadlocks and depending on how it's implemented, race conditions into the framework. There is also a performance consideration. Not so much ...


6

When the HTTP request is completed, it will return some data, and the model gets updated by the responsible part of your system. Then raise an event which tells everyone who subscribed to it "new data has arrived", but do not pass the actual data in this event, only the relevant information for the subscribers which part of the model has changed. The event ...


5

None of the above, actually. It is the responsibility of your controller to write the data to file, although I'd recommend writing a specific class for that and just having the controller use that class. It is not a view because views in MVC are strictly about rendering data in the UI. The data itself should probably be put into a model and that model ...


4

Part of the difficulty with any discussion of MVC is that different groups have co-opted it to mean different things. The implementation of MVC used in, say, a Rails app, would be almost unrecognisable to someone writing a Swing app. To the extent that MVC is still a well-defined thing, it's more of a set of guiding principles (separate the core application ...


2

Your model should never contain any actual code, and should be seen as more of a message or a struct used to manage content manipulated by the controller and displayed by the view. Your controller should be responsible for contacting any APIs, databases, services, etc... requesting a change and managing any necessary updates to the model. The entire ...


1

I think there's a missing concept here, which is UserSession. An user can have multiple UserSession (but only one active session at a time) So if I do the refactoring, it would be something like this (in .NET): public class UserSession { private DateTime _expireTime; //Other properties public bool IsActive() { return _expireTime ...


1

The 'displaySessionExpired' on your model simply does not belong there. It is the responsibility of your model to handle logic, but HOW it is displayed (what text and what color) is the responsibility of the view. It is up to the view to call hasSessionExpired and take the result to be displayed.


1

Your model classes should be simple and only store the data you wish to model for your application. You should avoid having any complicated methods or business logic in your model classes. I usually have constructors and basic properties (i.e. public getters, private setters) in my model classes and that tends to suffice. Your view model classes should ...


1

Might be way off here, but this is how I feel about WebApps and working with [complex] remote API's in many cases: I would make it a class (ie, a library of data mitigate methods) instead of model (ie, stack of data mitigate functions). It seems like it would act more transparent, more logic/schema agnostic, and you could use it wherever without ...


1

Here, the model is described like this: A model stores data that is retrieved to the controller and displayed in the view. Whenever there is a change to the data it is updated by the controller. I'd say that the controller either includes the logic of calling the service or calls a separate Service object. If the service is separate, you can more ...



Only top voted, non community-wiki answers of a minimum length are eligible