I just want to clarify this doubt. I might be wrong. I've learnt in OOP we should not repeat codes through out the classes according to the DRY principle. However, if I checked the admin settings context and the public context check boxes, bonfire will create two controllers in the module/controllers folder (in this case settings.php and mymodule.php). I can see the functions have been repeated. I feel like, I could just use one common controller for CRUD and load different public and admin views, or even for other context as well. Can some one help me to understand this? Thanks a lot!
Related
I have doubts whether every view should have its own ViewModel or should I pass the plain model where there is no need for ViewModel? (What concerns me is that if I start to mix these two concepts, then I will end up with jungle later on)
I tried to google it but no one talks about that, every post I run into just explains the purpose of ViewModel and I know that the main purpose of ViewModel is so you can pass multiple models to view.
It depends.
In many use cases the main purpose is not to expose fields to being bound on form submission that the user shouldn't be able to update. I wouldn't slavishly create them when not needed but it depends on the developers and their level of understanding on when and why you use viewmodels vs domain/ef models. Also application code base size makes a difference.
Maybe you need select lists, maybe you want to convert some properties to different types. Lots of reasons to use them. However it is more code and mapping code even if you use a tool like AutoMapper. So they cost time to implement but maybe they fix problems and save other time? Maybe they fix a security problem? Maybe doing them all the as view models helps juniors understand? Maybe you would rather do the setup of a viewmodel at start than convert code later when it is really needed?
Consistency can help but doing a bunch of extra work may not be worthwhile. Best practice for me isn't best practice for you.
Consider the costs and benefits for your project and team . E.g. maybe your project is internal and no one is going to try to hack via adding data to submission
There are couple of reason to choose ViewModel over DomainModel.
1) First thing first is the security. Imagin you have a view for changing the password. If you pass the domain model to the view. probably you are exposing a lot of properties which is not necessary and it may cause a security problem. There is no reason to expose properties like LastLoginDate, IsActive, IsEnabled, NumberOfFailedLogin and so on for just changing the password.
2) The second reason is reducing logic from the view. If you pass a Domain class to the view, Possibly you need to add some extra logic for hiding extra properties or shape it as you like or adding logic based on the route and etc.
3) Because of the architecture. Exposing domain model to the view cause tightly coupling between your presentation layer and domain model which is not good at all.
We have been using ExtJs for a long time, and now, with the advent of MVC pattern in it we are facing a critical question of whether to use it or not in the times ahead given the approach we had been following so far.
In our application, we have similar screens, like 40 similar screens for generating the reports and so on. These report screens would be having a form with buttons - PDF, CSV, EXCEL. All the buttons would be having same functionality at every screen, that is, submit the form to a url and generate the specific report.
The approach which we had been following was to create a custom class, say reportscreen class, which extends the window class of ExtJs.
This custom report screen class would already have buttons with their handlers defined (given the fact that the functionality is similar for them for all the screens) and will also have a form present with a function setFormItems(). Any instance of this class would provide the items for the form using setFormItems() and the url for generating the report.
This approach not only helps us in reducing the development effort to a great extent, but also allows even a new member of the team to use the class & create a new screen.
Now comes in MVC, the most advised pattern, and the approach shared above is definitely not as per MVC pattern. But then, do we need to really move to MVC pattern here?
Using the above approach, we are not only able to save the effort, but also have a greater control over things.
The purpose of asking this questions is to know about the exact advantages we shall get if we implement the above scenario using MVC pattern and move away from our current approach.
Thus, what extra things would MVC bring to the table in the context above? And also, what would be the best way to implement such a thing in MVC pattern?
Thanks for any help in advance.
Do you need to use MVC? No. Assuming you've already got a structure that works well for you, if it's not broke, don't fix it. If you were starting a new project I'd recommend using MVC, but I wouldn't refactor a whole bunch of code for the sake of it. If you did use MVC, you would follow a similar approach. You'd have a base view class where you dynamically push on the items in the subclass. You'd have a base controller to handle all the custom events, then subclass controllers to implement custom functionality on a "per module" basis.
It's hard to explain the advantages of using MVC to someone who had no experience with it. As someone who developed with both ExtJs 3 and 4 (with MVC), I think one of the greatest advantages of MVC is that it forces you to think right - whether you want it or not, using MVC is likely to result in code base that is more reusable and better encapsulated. But if you boys and girls are good programmers/designers, this will be the case anyway.
If you do choose to move to MVC, I believe that the main change will be in that now instead of handling user interaction within your custom class, you will have a single controller to do the same job - leaving your custom class to realize the view only. Controllers in ExtJs4 are global - meaning that the same controller may control 40 similar views. So no duplication of controllers here.
It's important to mention that even within an MVC design you will find non-MVC code. For example, I have a custom record editor which is a form - the component knows how to handle user actions and update the records accordingly (the form is not submitted as it's mostly dealing with associations). This component takes the equivalent role of both the controller and the view within an MVC design. It seems to me more than reasonable to encapsulate things this way, rather than split this to a view and a controller. But the (non-reusable) user screens are implemented using MVC. So maybe just another reason not to rush to MVC.
While I agree with Evan that if it aint broken don't fix it, had I been your development leader and given time and money is not an issue, I would actually request the gradual migration to MVC - overall I think that 3 years down the line you won't regret this decision. I would at least attempt it.
When ExtJs 4 came out I scraped 2 months of work to rewrite from scratch a system using MVC - I don't regret this for a second now (I did at the beginning, but not for MVC - rather for the amount of bugs in the early versions of 4).
I have some weeks since im using CI, but now I've found some problems about the structure of my project, I would like someone to give me some clues because I am kinda stuck, the problem is this:
I have my project MVC, so, I am dividing it into files (each per functionality) for example, there is a file with all the functions corresponding at login, and other with all related at post (it's an example), but now I am on a moment where I need to use login or posting into another part of the project, reading I found out i cannot call a controller from another, I can use the helper but still I will need to use a model, so I have to take that code and paste it into the controller where I'm calling the model and so on (and it's not good), I found out I can use modules, still I don't want to go over them until someone could give me an experience of this, i wouldnt like to change the project, is any way I could run all those controllers (i know i can use run:: I'm not sure if i can send parameters in it), any ideas please?
Thanks in advance.
Fair warning, this type of question will get shot down by many SO moderators, but I'll give you some tips regardless:
Controller actions are single-use. If you find yourself with duplicate code in multiple controllers (or, needing to call a controller function from another controller), that's a sure sign you should move that code to a model or library.
Models are object-specific, not action-specific. I wouldn't have a model dedicated to logins, unless you have multiple types of logins (most apps/sites just have member logins, but you might have administrators, etc. that are stored in a different table from the rest). Instead, have a User_model class, and make function login($email, $password) a method of that class.
Controller-to-model interaction should be very concise. If you find yourself with 30 lines of code passing data back and forth between the same controller and model, you might be trying to do too much with that one controller action.
Keep your models fat, controllers skinny, and views dumb.
I have MVC app and when I create I start with one controller for my domain model Person. I have actions including AddPerson, DeletePerson, EditPerson, etc. Then I start adding more like AddPersonBoss and RemovePersonBoss. Pretty soon I have 20 actions in one controller. The benefit of MVC becomes less apparent because my file contains several hundred lines of code and is difficult to follow.
All examples I see show one controller per domain object such as Person. It feel like I should have a PersonManagement controller for AddPerson, DeletePerson, EditPerson and a BossManagement controller for AddPersonBoss, RemovePersonBoss.
Does this make sense? Why would I not want to break it into several controllers? Too many action in one controller becomes difficult, but all examples I see do this.
I would suggest to use both approaches, because sometimes it is a bit difficult to use only one particular approach. If controller is growing significanly then consider to split it into multiple partial classes.
that is depend on your application
i prefer to make a controller for each operation because that makes my controller code simple
but if you have a lot of operations that will lead to creating a lot of files for each
controller so then you have to make one file to group some controllers together to make the
application simpler
I just read a blog post that explains MVC with a banking analogy. I have a few months of experience with web application development with an MVC framework (CakePHP), so I get the basics, but I began to see a theme that made me think I'm taking a flawed approach to where I put my logic:
Fat models, skinny controllers
Keep as much business logic in the models as possible
In my app, models are anorexic and controllers are obese. I have all business logic in the controllers and nothing besides associations and validation rules in the models.
Scanning through my controllers, I can now identify a lot of logic that should probably go in a model:
The app has lists, which contain items, and the items can be ranked. The sorting logic which puts the list in ranked order is in a controller.
Similarly, items (Item model) also have images (Image model). Each item may have a default image (designated by image_id in the items table). When an item is displayed with its images, the default image should appear first. I have the logic that does this in a controller.
When a list is displayed, related lists are displayed in the sidebar. The logic to determine which lists are related is in a controller.
Now to my questions:
With the examples I gave above, am I on the right track in thinking that those are instances of logic presently in a controller that belongs in a model?
What are some other areas of logic, common to web apps, that should go into models?
I'm sure identifying this problem and changing my design pattern is half the battle, but even if I decide to take those examples I gave above and try to move that logic to a model, I wouldn't know where to begin. Can anyone point me in the right direction by posting some code here, or linking to some good learning resources? CakePHP specific help would be great, but I'm sure anything MVC will suffice.
It's a bit tough to give you the "right" answers, since some of them deal with the specifics of the framework (regardless of the ones you are working with).
At least in terms of CakePHP:
Yes
Anything that deals with data or data manipulation should be in a model. In terms of CakePHP what about a simple find() method? ... If there is a chance that it will do something "special" (i.e. recall a specific set of 'condition'), which you might need elsewhere, that's a good excuse to wrap inside a model's method.
Unfortunately there is never an easy answer, and refactoring of the code is a natural process. Sometimes you just wake up an go: "holy macaroni... that should be in the model!" (well maybe you don't do that, but I have :))
I'm using at least these two 'tests' to check if my logic is in the right place:
1) If I write a unittest, is is easy to only create the one 'real' object to do the test on (= the object that you are using in production) and not include lots of others, except for maybe some value objects. Needing both an actual model object and an actual controller object to do a test could be a signal you need to move functionality.
2) Ask myself the question: what if I added another way to use these classes, would I need to duplicate functionality in a way that is nearly copy-paste? ... That's also probably a good reason to move that functionality.
also interesting: http://www.martinfowler.com/bliki/AnemicDomainModel.html