In MVC, 1 model 1 tables or 1 model several tables?
I am building an application that contain 3 tables. I don't know whether I should create one model for all 3 tables or create 3 models for 3 tables.
In the case I use 3 models for 3 tables, where should I put the code if I want to join these 3 tables? Put the code in any one of 3 models?
Any suggestions?
In general, the 'Model' part of MVC should be interpreted as a 'Presentation Model' or 'View Model' - that is, a class that encapsulates all the data and behavior needed by the View. This may or may not be equivalent to the Domain Model.
Domain Models should be designed to be independent of UI. This means that such Models should not be polluted with UI-specific data and behavior - such as determining whether a particular button is enabled or not.
You may also want to show the same Domain Objects in several different views (e.g. Master/Detail, or Display/Edit), and if those views differ sufficiently, having a View Model for each View will be beneficial.
So, in general, you should design your Domain Layer and your Presentation Layer independently.
In the Domain Layer, you can choose to model your three tables as three classes. Books like Fowler's Patterns of Enterprise Application Architecture and Evans's Domain-Driven Design contains lots of guidance on how to model relational data as Domain Models.
When it comes to modeling the views in MVC, it makes most sense to create one Model per View. Such a View Model might simply encapsulate a single Domain Object, but it may also encapsulate and aggregate several different Domain Objects.
In this way, you can ensure separation of concerns, and that your classes follow the Single Responsibility Principle.
For very simple scenarios, it may make sense to collapse the Domain Model and the Presentation Model into one layer, but you should realize that this essentially means that there's no Domain Model in the solution - all models would be pure Presentation Models.
Usually you will create one model per table, so in your case it means you need 3 models.
When i say "Model" i mean a class that will represent a single row (usually) in a single table.
for example:
Tables:
Products
Orders
Customers
in such case the most easy and simple is to create 3 different classes (which represents the data model of the application) where the first class represents a single product the next represents an order and the last class will represent a single customer.
Related
in MVC design pattern, we have three sections: model,view,controller. view and controller meaning are straight forward. but what is the meaning of model exactly? why model term??
in other hand, is this a correct approach to write database interaction functions in model?
In the MVC pattern, the model holds the data and define the logic to manipulate your data.
Each view will read from the corresponding model in order to display the data in multiple ways.
There reason you need a model is because of separation of concerns. You can have one model that is your user list for example, and you can have two views that display this list according to some criteria. This way, if you need to change your views, you don't need to touch the model and its logic.
I recommend this article on the evolution of the MVC pattern for more details.
I have programmed in Rails, Django, Zend, and CakePHP. Also, Wordpress and Drupal.
Now, I am "catching up to speed" in as fairly large application in CodeIgniter.
Typically, my experience with MVC frameworks, has led me to believe that Models represent business logic in reference to actual database tables. In the CodeIgniter docs and in the code base I'm dissecting I see models created that represent something as vague as a page. A lot of the business logic is written directly into those models and they incorporate other actual data models. I'm not sure this is ideal and following MVC.
Should models be created beyond data models?
Also, lets say I have a data model representing a user (user table in DB). In that user table there is a column called gender of the type enum('male', 'female'). Now I want to populate a dropdown with the gender options from the enum column.
Where is it most appropriate to put this logic?
The user model is an object used to represent a single user or row in the db... right? So it doesn't seem fitting to include a function in the user model/class called "get_gender_options", because, while the function is related to the user table, it is NOT relevant to a single user object. In Zend this kind of logic could be built into the form object itself.
There is not "right" answer, just one we can consider the most appropriate...
I would probably just put the "get_gender_options" in the model, rather than sticking it in the view for the form. To keep it DRY but not put it in the model, I would create a helper to hold this.
I am wondering how the models in code ignitor are suposed to be used.
Lets say I have a couple of tables in menu items database, and I want to query information for each table in different controllers. Do I make different model classes for each of the tables and layout the functions within them?
Thanks!
Models should contain all the functionality for retrieving and inserting data into your database. A controller will load a model:
$this->load->model('model_name');
The controller then fetches any data needed by the view through the abstract functions defined in your model.
It would be best to create a different model for each table although its is not essential.
You should read up about the MVC design pattern, it is used by codeigniter and many other frameworks because it is efficient and allows code reuse. More info about models can be found in the Codeigniter docs:
http://codeigniter.com/user_guide/general/models.html
CodeIgniter is flexible, and leaves this decision up to you. The user's guide does not say one way or the other how you should organize your code.
That said, to keep your code clean and easy to maintain I would recommend an approach where you try to limit each model to dealing with an individual table, or at least a single database entity. You certainly want to avoid having a single model to handle all of your database tables.
For my taste, CodeIgniter is too flexible here - I'd rather call it vague. A CI "model" has no spec, no interface, it can be things as different as:
An entity domain object, where each instance represents basically a record of a table. Sometimes it's an "anemic" domain object, each property maps directly to a DB column, little behaviour and little or no understanding of objects relationships and "graphs" (say, foreign keys in the DB are just integer ids in PHP). Or it can also be a "rich (or true) domain object", with all the business intelligence, and also knows about relations: say instead of $person->getAccountId() (returns int) we have $person->getAccount(); perhaps also knows how to persist itself (and perhaps also the full graph or related object - perhaps some notion of "dirtiness").
A service object, related to objects persistence and/or general DB querying: be a DataMapper, a DAO, etc. In this case we have typically one single instance (singleton) of the object (little or no state), typically one per DB table or per domain class.
When you read, in CI docs or forums, about , say, the Person model you can never know what kind of patter we are dealing with. Worse: frequently it's a ungly mix of those fundamentally different patterns.
This informality/vagueness is not specific to CI, rather to PHP frameworks, in my experience.
I’m having a philosophical problem with understanding how to use Models on MVC3.
I believe the problem lies from the fact that I come from WebForms :--)
Let's say I have 10 tables on my DB and as expected when I get them into my EF4, I get those Entity classes that represent the tables (and all their FK integer values).
When I want to display data on the View, I cannot display a select * from table because those FK integers means nothing to my users …and also because some data lies on related tables.
So my understanding is that I can create a Stored Proc, create a Complex Type that represent the actual data to display, coming from separate tables via different SQL joins.
QUESTION 1:
On the view, id MVC compliant to use as #model ..that Complex Type?
or shall I always use Models that are created on the Models folder? And if so, does that mean that I have to replicate the Complex Type on a new model inside the Models folder?
Question 2:
Is this the right way …to create specific SP to collect data that will be displayed or ..is it better to use linq and lambda to be applied to the EF4 Types that come from importing the DB into the EMDX designer.
Thoughts ??
FP
The correct way is to always define view models. View models are classes which are specifically tailored to the needs of a given view and would be defined in the MVC application tier. Those classes would contain only the properties that would be needed to be displayed by the view. Then you need to map between your domain models (EF autogenerated classes?) and the view models.
So a controller action would query a repository in order to fetch a domain model, map it to a view model and pass this view model to the view. Top facilitate this mapping you could use AutoMapper. A view shouldn't be tied to a domain model and always work with a view model. This works also the other way around: a controller action receives a view model from the view as action argument, maps it to a domain model and passes this domain model to the repository in order to perform some action with it (CRUD).
So a view model could be a class that is mapped from multiple domain models or multiple view models could be mapped to a single domain model. It all depends on how your domain looks like and how do you want to represent the information to the user.
As far as validation is concerned, I distinguish two types: UI validation and business validation. As an example of UI validation is: a field is required, or a field must be entered in a given format. A business validation is : the username is already taken or insufficient funds to perform wire transfer. UI validation should be done on the view models and business validation on the domain models.
I'm not sure why you need to use a stored proc, LINQ to Entities is able to generate complex types without needing to create stored procs (in most cases). You select subsets of data, just like you would with regular SQL.
As Darin says, the use of a View Model is appropriate for situations where you have a lot of complex data that isn't represented by a single entity. This View Model would contain multiple entities, or even multiple collections of entities. It all depends on how your data needs to be consumed.
I can't quite decide how to go about separating my view models from my DB models.
I'm using an ActiveRecord pattern for my DB access. Meaning I get a User class instance for each User row in the database.
In WebForms I'm used to use these as my model objects, implementing most of the business logic directly on my ActiveRecords.
I realize this isn't exactly 3-tiered design, and I'd really like to improve upon it, especially in MVC, where separation of concerns is empathized.
So I'd think the Controller shouldn't have access to my DB models, but how do I then go about storing/loading data from the DB ?
It's not my impression you should place a huge amount of business logic in your view models either, so somehow I think I'm missing a central piece of the puzzle.
What I'm looking for is some best-practice advice I guess :-)
I hope all this made sense, otherwise please ask.
I strongly suggest creating one view model per view and using AutoMapper to map properties from your active records to your view models. I don't believe that there's a problem with your controller having access to your DB models; the controller should be responsible for translating them into view models.
As for translating view models (really post data models) back into active records, you can use AutoMapper for this as well in simple cases and custom code for the rest.