Hot answers tagged

6

View is a layer responsible for displaying information which may be interpreted by a user/client of your application (it does not say the user has to be an actual person). JSON is completely valid format for a view layer, computers understand that. As long as the view layer publishes information which can be used by a user to affect models in your ...


5

Is creating methods such as isUserAdmin() bad practice? It is, though it isn't so much that this method is bad practice, but rather using a parent class as a dumping ground for methods you want to share with the child objects but that don't have any particular relationship to each other in terms of behaviour is a bad idea. If the method was a core ...


5

I would go for option 1, since your controller does not need to know about your view to do his thing. If you chose option 2 your controller needs to know about the view. If there are changes to it, you need to change the controller too. Another advantage would be, that you can easily switch your UI. In the new UI you can call the method in your controller,...


4

Yes your feeling is good. It's not right to have such methods inside Model. 1a. Models should only contain properties (in my opinion). 1b. Data-related methods like your SQL fetching should be encapsulate within Repositories. Repository pattern helps abstracting out the database connections we are using. Says you have dozens of models like this, and one ...


4

MVC is a paradigm from the Smalltalk world concerned with how object orientated systems could have UIs. Early web frameworks took the general idea (separate out business logic, controlling logic and view logic) and applied the principle to how they structured the web application. Before this it wasn't uncommon to have God awful mess of HTML generation code ...


3

Are you over-architecting your app? MVVM is a great way for organizing logic for an application that would otherwise become too complicated. But sometimes it can be overkill. You mention you end up having all the model logic in the ViewModel, and that doesn't seem to be giving you any problems. If there's no practical reason you need to separate your View ...


2

I might get down-voted for telling you not to use OOP, but: don't use OOP. I will try to explain why without running out of space :) Particularly I am drawn to an approach that promotes reusability, modularity, understanding (reusing understood code), and more. Of course you are! That's what all software engineers strive towards. It's the holy grail....


2

Do we really need a Value Object and Data Transfer Objects for every use case? Why not send back entities? OK, I'm only going to try to answer this one of your many questions. Option 1: If your database exactly models your business, and there are no arcane business rules, then by all means use entity objects in your GUI layer. The programming will be ...


2

DAO code goes into the Model, not the controller. DAO code is actually farther away from the controller than the business logic, and that logic doesn't go into the controller either. Write a layer that contains methods that convert CRUD operations (Create, Read, Update, Delete) into DAO operations. Call the newly-created CRUD methods from your controller ...


2

I would not go too far in determining how people should spell their own name. There is probable more variation in names in the world than you can capture with your automated rules. I know someone named "d'Agano" and he is not amused if you 'correct' his name by capitalizing the 'D', remove the apostrophe or lowercase the 'A'. There are scores of people ...


1

Is that how it is should be done? Passing the JSON as a view, or using it as a view model to construct the view does not violate the pattern. I am using the same architecture in the current application I am working on and it is working very good. Together with some nice JS framework you can create some really responsive designs. Or are there any other,...


1

You use common sense. I might care a lot about whether the user is an administrator and add a method for that. I might care a lot about the user service object of the controller and use it a lot, for all the purposes that a user service object is designed to be used for. In that case I'd add a method for the user service object. I suspect that I don't ...


1

Two points: I prefer methods like these because they help break up method trains like: myObject.getFoo().doBar().tooManyCalls() (i.e. Train Wrecks) However, If you find yourself writing several of these "shortcut" methods you may very well have a bigger/better refactoring that you can take advantage of. See Bob Martin's book "Clean Code" and code-smell ...


1

Really it boils down to, do you want to be able to alter the ordering externally? So what I mean is; you have a page /MyController/orders. By default this is ordered ASC. If you want to have a link (somewhere else external or internal) that goes directly to the non-default ordering. Then I'd put this into the action as a parameter (option 1), this allows ...



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