When designing a class diagram for a theoretical MVC-Pattern-based system, is it best to use List classes?
For example:
With List class:
Without list class:
I personally feel the latter is a better approach due to less code duplication, is there a better approach to this?
I don't think there is a need for a list class. Your controller can hold all references to the model.
Regardless of that, your UML models have a problem: in both cases you have an attribute customers:Customer[] and an composition link. This means that you have TWO references from the controller (or list) to the model. Either remove the attribute or the link.
I would suggest you to use swimlanes, one lane per structure component (MODEL / VIEW / CONTROLLER) and a separate lane for the database
a sample example would look like this
Related
I wonder about the route leading to the welcome-page in my project. You reach it with the '/'-route .
Where should the method handling this route be and what is the correct structure behind it?
I get two ideas spontaneously:
Make a model named something like Home and put the method in HomeController
(Con: I thought all modells should be represented in DB?)
...
Make only a controller named HomeController, no model
(Con: Feels wrong to have a controller for a modell that does not exist?)
What is correct?
I can't comment so I'll leave it here.
Both Model and Controller are just Class. If you take a look at your HomeController and your User.php model you'll see they extend Controller and Model Classes, respectively.
As many said there is no need to have 1 to 1 relationship between Controllers and Models.
Invest some time to learn basics of OOP and you will see that you can have as much classes as you want, and there are many ways to relate them. Some of the Classes are Controllers, some are Models and some are something completely else, like Exceptions. But at all times keep in mind that, in the end, they are just Classes implementing some interface, using some traits, and extending other Classes.
It's worth to do this at the start of your learning process. It will steepen your learning curve a bit but in the long run it's well worth it.
You don't need a model for each controller or vice versa, just add them as needed according to your application: need CRUD actions or other interaction with your model. Try creating a WecolmeController as the HomeController is the default one for after login features (or change it accordingly if needed).
I'm using IBM Rational Rose, but I'm not sure if I'm able to model/design the methods/procedures which are known as "operations" within a class onto "UML User Class Diagram". Is there any way to model the algorithm or the code of 'operations' (i.e something like flowchart) via the software? If so, is there any possibility to get the methods design auto-implementation integrated via code generation in order to define them within a java source file?
Another way to model behavior is to use StateMachine, Constraints, Sequence and Timing diagrams. Of course, you can simply write Notes describing behavior in plain words.
You can use activity diagram, activity diagrams are near a flow chart.
See rsa activity diagram
On your activity diagram, you create a partition and you can link your partition to you operation. Then you create callOperation action which can be linked to method call.
I create a class diagram with 4 class Class1, Class2, Class3, Class4, each one containing a method operationx.
And here is a simple example modeling operation1. The important point is that the partition named Operation1 is linked in the UML model to Class1:operation1 and the 3 actions are linked to method operations. This is not a "typo" tips.
You can look also to sequences diargam but it does not look like a flow chart.
Should methods that manipulate the Model class members be implemented in the Model or in the Controller? Does it depend on how "heavy" this manipulation is ?
By "manipulation" I mean:
get a class member
make a long calculation based upon this class member
return another value which relates to this class
For example, a Board class which hold a cell matrix member.
Now I want to implement a method which returns all the surrounding cells according to specific cell location.
Is the model or view responsible to for implementing the above ?
If this question belongs to another Stack Exchange QA site I will welcome the recommendation to move my post to that site.
Keep your controllers thin, don't let them do much, this aligns with the Single Responsibility Principle in SOLID for Object Oriented Design. If you have fat controllers, they become hard to test and maintain.
As for the models, I used to have dumb models before that did nothing but to map to database tables and that was inspired by most of the sample applications that you see on the web, but now I don't do that.
I (try to) follow the principles from Domain Driven Design, where models (entities in DDD terms) are at the center of the application, they are expected to encapsulate behaviour related to the entity, they are smart models (so yes, the logic related to an object will live with it in that case). DDD is a much bigger topic and it is not related directly to MVC, but the principles behind it helps you better design your applications, there is a lot of materials and sample apps available if you google DDD.
Additionally, Ruby On Rails community - which seems to inspire most of MVC frameworks - also seems to have a hype around having Fat Models and Skinny Controllers.
On top of that, you can add View Models to your mix which I find helpful. In this case, you can have a ViewModel to represent a dumb subset of your model(s) just to use for generating the view, it makes your life easier and further separate your Views from your Models so that they don't affect your design decisions unnecessarily.
What you call "model" is are actually domain objects. The actual model in MVC is just a layer, not concrete thing.
In your particular example, the Board should have a method that returns this list. I assume, that you are actually acquiring it because you then need to do further interaction with those cells.
This is where the services within the model layer comes in to play. If you use them, they are the outer part of model layer and contain the application logic - interaction between different domain objects and the interaction between the persistence (usually either data mappers or units of work) and domain objects.
Let's say you are making a game, and you and player performs and AoE attack. Controller takes a hold of service, which is responsible for this functionality and sends a command: this player aimed AoE in this direction, perform it.
Service instantiates Board and asks for surrounding cells of the target location. Then it performs "damage" on every cell in the collection that it acquired. After the logic is done, it tell the Unit of Work instance to commit all the changes, that happened on the Board.
Controller does not care about the details of what service does. And it should not receive any feedback. When execution gets to the view, it request from model layer the latest changes and modifies the UI. As the added benefit - services let you stop the business logic from leaking in the presentation layer (mostly made up from views an controllers).
The domain object should contain only methods, that deal with their state.
I think this has little to do with MVC, and a lot more to do with regular software engineering.
I personally wouldn't hesitate to stick trivial calculations in a model, but would be extremely wary of fat models.
Now, the fact that MVC stands for Model View Controller doesn't necessarily mean that everything should be either a view, a model or a controller. If you feel the need to move responsibilities to a separate class that doesn't really qualify as an M, a V or a C, I don't see why you shouldn't do it.
The way you implement it is up to you. You could either use this separate class as a "top level" (for lack of a better term) object, or make a method of the model delegate to it, so as to hide the fact that you're using it. I would probably go for the latter.
Everything is debatable, though. Everybody and their sister seem to have a different opinion on how to do MVC right.
Me, I just consider it a guideline. Sure, it's a great idea because it leads you to a better separation of concern, but in the end—as it always happens—there's no one-size-fits-all way to apply it, and you should not be overly constrained by it, to the point where everything has to be either a view, a model or a controller.
As per best practice we should use properties for Calculated fields with get access only. example public double TotalCost {
get
{
return this.Role.Cost * TotalHour;
}
}
In this book (the link goes to the part I'm interested in) it is suggested that you could use a single instance of Zend_Form to put both Model and View validations. I'm wondering exactly how to do this, considering the forms will probably not correspond exactly to the structure of the models. How can this be achieved? It sounds logical to not duplicate the code that does validation, but I have always done it separately.
This article from ZF Project Lead Matthew Weier O'Phinney explains one approach:
http://weierophinney.net/matthew/archives/200-Using-Zend_Form-in-Your-Models.html
I am new to MVC but I can already see its benefits and advantages. However, I have a (probably easy to answer) design question:
I have been thinking about models and debating the proper way to structure them. The way I see it there are a few options:
1) Models and table structure have a 1 to 1 relationship...meaning that pretty much for every table there is a corresponding model. The model class has attributes corresponding to the table columns and has whatever methods that are needed (like getters and setters) to manipulate data in the table in whatever way is necessary. This seems like the generic option and I guess I would then have the controller call the models as necessary to perform whatever business function is necessary.
2) Models are tied more closely to the operation of the business logic rather than the data: so for example if on the front end a deletion of a certain object affects multiple tables, the model then 'models' this behavior and interacts with several tables and performs the necessary function. The controller then simply needs to call a single model for whatever business behavior is desired. This is less generic since the models are much more tightly coupled..but seems quicker to implement.
3) Something in between the first 2 options. Or maybe I am completely missing the point.
Hopefully this makes sense! If I am not totally missing the point, I am inclined to think that option (1) is better. Any idea?
Edit: Not that it should matter, but I plan on using Codeigniter PHP MVC framework.
Both are valid implementations, and, depending on your needs, can work well.
Your #1 is essentially describing the Active Record pattern, which is used by SubSonic, Castle, and lots of other ORM implementations.
Your #2 is essentially describing the Entity Framework/Hibernate/LightSpeed approach, where you are dealing with objects that are more conceptually related to your domain rather than to tables. Instead of your objects containing foreign key ID properties, they actually contain the other domain object references, which are then instantiated in an on-access basis.
Both ways are great. The Active Record approach is usually more intuitive for beginners and has potentially less pitfalls. EF-style can save a lot of base-level coding and dealing with FK's directly in code.
Edit: To be clear, what you describe in both situations is data access layer related, rather then strictly model related. However in reality you're pretty close, as most models tend to simply represent one or more of these types of objects.
All of the above.
The approach you use depends on your design philosophy. If you prefer to design your application using business domains and drive that into the database design, then you favor the second approach. If you prefer to build your database first, and then create model classes from the database schema, then you favor the first approach. Both methods are valid ways to build software.
Number 1 is the way to go. Option 2 is really the controller's job. For example, the controller then takes the models and performs actions on them, and passes the results to the view.
Think of it this way:
Model = your data
Controller = business logic
View = display of data and actions
This is highly simplistic, but it's how I picture it in my mind when I go to design a system.
Think of the database as the Model, the business logic as the Controller, and the UI as the View. That may help. It's an overly simplified approach to things, but it gets the data / behavior separation roughly correct.
I don't think it has to be an either/or situation. Your first point is what would be called a Model, but your 2nd point sounds like a View Model, which is most often a composition of various Models and parts of Models that will be sent to the view. The controller is responsible for doing that composition and potentially decomposition when information is sent back from the View.