Tag Info

New answers tagged

1

Like any other utility class/helper function/convenience whatever, where to put it depends on who's using it. If only M uses it, then maybe it belongs in the Model folder. If your M, V and C are all using Dates, then maybe Date belongs in a separate folder from all three. You don't have to put every piece of code in one of those three folders.


0

I would use approach 2, putting it on the Comment model. I'd name the method something like loadAllCommentsForPost though, to clarify that it doesn't just load every single comment from the database. Though approach 1 wouldn't be too bad, consider that you might have a lot more models relating to Post later on. You wouldn't want your Post model cluttered ...


0

I think you are missing 1 or maybe 2 layers in your design which is why you are not sure where to put business logic or 'builder' code. You should consider adding a service and possibly repository layer. The service layer is a layer that interfaces between controllers and the model/repository. It may contain business logic or may just be a thin API layer. ...


0

So in the ideal world your controller should not contain any business logic or business objects. These should be completely located in your domain model layer. Referencing to "Patterns of Enterprise Application Architecture" by Martin Fowler the controller is even part of the presentation layer, so only responsible to pass the input data to your business ...


1

In MVC, the model (that is an instance of a model class) is nothing more than an ordinary object. It is initialized by the controller which passes it to MVC's engine which, in turn, uses it when generating the final result from a view. If you're asking whether it is stored on the stack or on the heap, the response is: on the heap. Instance variables for ...


-4

You can use angularjs for the front-end and codeigniter or another php framework for the back-end without any issues. You just have to keep in mind that both are MVC (Model-View-Controller). Why use similar concepts but with different structures? Because angularjs works with template HTML and all views are HTML (not including the header and footer). As ...


2

It really depends on the structure of the page. If a page has only one purpose and one concern, then you should try to use a single controller so that the code is grouped logically. If there are multiple components on a page with different concerns, then you should absolutely use multiple controllers for the sake of decoupling. For example, consider a page ...


1

Just some thoughts, continue to do your research on best practices. First, respect encapsulation and avoid tight coupling between views. Consider using dependency injection to inject inner views into outer views in your hierarchy - or decorating, etc. depending on the use-case. Is there a specific functional reason you want two-way chainable calling ...


0

It's really a matter of opinion. In the standard MVC pattern for web applications, you have one controller per action the user performs, but like many other modern implementations of the pattern, Asp.net MVC allows you to have multiple actions in a single controller class. Grouping them by entity they affect is one option, as is having a class for each ...


1

You use a controller when you have a need to access a resource externally. So if you're building an interface to modify employee information, then you have a need for a controller there. Just because you have a resource, though, doesn't mean you need a controller for it. Suppose you have a location class/model that refers to addresses. Maybe an employee has ...


0

The whole point of MVC is decoupling layers from each other. UI work can be done independent of business rules. Business rules can be crafted independently of the UI or data access. And the Model can mine away all the data it wants independently of the Business rules. Notice that the UI and Model shouldn't ever know of each other. "Business logic" about ...


0

A controller is the mediator between the model and the view. Essentially, the controller reads the user input from the view, and updates the model in accordance to the changes. Without a controller, the view will be too tightly coupled with the data model. If you were to change one small thing in the model, it could completely screw up the view. Whereas if ...


0

you can use ORM (object relational mapping) like JPA or Hibernate. when you are using ORM in your model, you dont need to re-query the related object because ORM will handle it for you automatically. for example: define your model class and it's relationship: class Product { Manufacturer manufacturer; //setter and getter } class Manufacturer { ...


0

IMHO, Model-View-Controller (MVC) design pattern purpose is to separating your application concern into Data (model), Presentation (view) and Business logic (controller) to increase the reusability and maintainability of your code[1][2]. In MVC design pattern, the controller component contains every method in your application which have the same domain. Lets ...


0

Architecturally "search" is no different from "getCustomerDetails" its a request, the system reads a datastore to get the data and the result is formatted for the screen. "Replace" is really no different from "changeAddressDetails" a request is sent, the data store is updated, and details of the update are displayed to the user. The MVC paradigm is meant ...



Top 50 recent answers are included