I'm trying to view data in business model level, since we have done data transformation in business model, how view the data in business model as we see in physical model.
You don't. You model things, then you expose them through Subject Areas which you then use in the presentation server - Answers or DV.
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 am working on a project that has a large database with all the data already in it. So now, I don't see the mvc project model being used very much, since the views are being strongly typed to a database model.
I am very new to this stuff, so is database simply taking place of the model "space" ?
since the views are being strongly typed to a database model
That's wrong. You shouldn't pass any domain models to the views. You should be using view models which are classes specifically designed for the requirements of a given view. A controller action should query your data access layer which will return some domain models and then map those domain models to view models and then pass this view model to the view. A view model is a representation of the database for a specific view.
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.
I am just getting started with MVC, and it seems like it will be a great way to go, once I manage to switch my thinking to it.
Most of the material I have come across seems to have a 1-1 relationship between models, views, and tables - ie each model represents a table and allows CRUD, plus more complex functions.
What if I have an Account Model, which would allow account creation and updating.
I would want to use a /signup view and controller to create() the account, but would want to use a /members/account view and controller to update, change pw, etc.
Would it be better to have a Signup Model, or am I ok with just using whatever model I need from multiple locations?
Also, say an account can have many users, but I want to create the first user at signup. I would like to run the account setup and user creation as a transaction. Should I have an Account Model and User Model, and work with both, or just have the signup create() function for Account create the default user?
I am using PHP with CodeIgniter
In general, what you want to do is most likely to consider your tables to be an additional "layer" below your model; the MVC concept generally doesn't deal too much with the implementation of backing issues; i.e. whether or not you're using DB tables or flat file storage or in-memory data representations.
What I would suggest is to look at the problem as one of having one layer that does interaction between your tables and your application; your "data objects" layer. Think of this as pure serialization. If you're using an object model, this will be your ORM layer.
Then you want to have another layer that defines the "business logic"; i.e. the interaction of your data with your data. This has to do with things such as how the Account interacts with the User, etc. The encapsulation here basically takes care of your high-level interactions. In this way, you can define the abstractions that make the most sense for your business requirements without needing to depend on implementation; for example, you can define a "UserAccount" Model, that will do all the things that you need to do to handle User Accounts; define all the things that you want that abstraction to do. Then, once you've got that abstraction down, that is your Model; you can then define, in the internal workings of that model, how the interactions occur with your persistence code.
In this way, you abstract out the persistence and implementation of your Model from the actual Model interface. So you can define your model as doing the things you want it to do without concern for the underlying implementation. The benefits of this are significant; the process of thinking about what you want your Model to do, in isolation from the way in which it will be doing it, can be very instructional; as well, if your backing data layer changes, your Model doesn't need to change; so you can prototype with a flat file, for example.