I start learning asp.net core
and see that in the views file < razor pages > you always can using object #Model of ViewModel class in your view,
What I want to know that is kind of architecture pattern use here, is MVC or MVVM?
From your description, I assume you want to know, whether the Asp.net Core Razor page's page model is an MVC architecture pattern or MVVM pattern, right? I suggest you could check this article.
The main purpose of the Razor Pages PageModel class is to provide clear separation between the UI layer (the .cshtml view file) and processing logic for the page.
A View Model is an implementation of the Presentation Model design pattern. It is a self-contained class that represents the data and behaviour of a specific "view" or page. The view model pattern is used extensively in MVC application development, where it mainly represents data, but typically little behaviour. In Razor Pages, the PageModel is also the view model.
Razor Pages is sometimes described as implementing the MVVM (Model, View ViewModel) pattern. It doesn't. The MVVM pattern is applied to applications where the presentation and model share the same layer. It is popular in WPF, mobile application development, and some JavaScript libraries. A main feature of MVVM is that the view is updated automatically to reflect changes to the underlying model. This process is usually controlled by two way binding and an implementation of the Observer pattern. In a server-side web application, the model resides on the server and the view is on the client. You need to implement additional complicated layers to achieve anything like the Observer pattern in such a distributed architecture.
Related
I am working on understanding MVVM better, and from trusty Wikipedia (and lots of other research), I have gathered that the ViewModel holds presentation logic and the Model holds the business logic.
MVVM Pattern (Image courtersy of Wikipedia)
My question is, how is there a separation of concerns between logic and data when the Model is holding the business logic? Why is this a good pattern and why would I want to use it instead of using MVC where the Controller handles business and presentation logic (if I understand it correctly)? (I am using WPF, which based on my research, mainly uses MVVM and rarely uses MVC, and I still don't understand why).
Separating presentation logic from business logic allows you to change business logic without directly affecting presentation logic.
For example, if you have a RESTful web API that retrieves some data a view should render, the ViewModel should not be directly handling the HTTP operation or any translation of the incoming data. The ViewModel should ask a (separated) service class to retrieve that data and then the ViewModel can choose how to present that data, such as by pagination, sorting, filtering, and so on. You may choose to paginate at the web API level instead, but that's an implementation detail. In the event that your API contract changes, you can change the web API service without affecting the presentation logic: separation of concerns.
Let's get some things straight:
MVC = Model View Controller
MVVM = Model View ViewModel
With MVC, the controller controls the data and the business logic, the model stores the data temporarily, and the View can read the data from the model. In this model, the View handles the presentation logic. In C#, you can use Razor Pages (.cshtml) to dynamically insert values into the view.
MVVM is very similar. The Model is responsible for holding the data and business logic, the View Model holds the data temporarily, and the View controls the presentation logic. The main difference is the physical separation in your code.
With MVC, each step is separated into its own file. With MVVM, usually two or more steps are combined together into one file. This can be advantageous because it keeps you from having controllers that are hundreds or thousands of lines long if you have lots of pages. I personally still like MVC, because it keeps everything separate instead of combining it together.
So I was first introduced to the idea of a model when I learned WPF. The MVVM concept of a model seems to be more aligned to general 'business logic' encased in a class/set of classes. When I look at MVC though, the model seems to be lightweight-classes that are "passed" to and from the user via forms. Is this assessment correct, or are there situations where a model is something heavier (does more than just hold and validate data input from the user).
You can use Models (classes) as data container (which i usually do) , look at anemic domain model (http://en.wikipedia.org/wiki/Anemic_domain_model), then you can implement business layer, service, data layer independently.
Or you can implement them within your model, which some folks wants to do that due to encapsulation, and several design priciples.
Look into domain driven design as well. (http://en.wikipedia.org/wiki/Domain-driven_design)
Well in MVC or another similar Design Pattern you have defined 3 separate layers of your application. The model with the logic of your objects, the view for showing and getting information from the user, and then a controller witch does the interaction and exchanges between the 2.
MVC is more used for web apps and MVVM with WPF. The reason is that you with WPF can do the databinding of the objects in your View with the one in the ViewModel.
For example a Twiter app: You can do have a model (tweetItem) with all the properties of a Tweet, a ViewModel that gets and stores the tweets in an collection and view that has a list, for showing them, binded to that collection.
There for MVVM or MVC only impact in your app is on how the code is organized.
I have developed a WPF-application. I have a mainwindow which inherit from Window, a tabcontrol and many tabitems in this tabcontrol which inherit from UserControl. Every tabitem has its own cs-file, where I code in C# all the businesslogic, and a XAML-file where the development of the UI is done. I also have a SQL Server with a database which i connect to trough LINQ.
So i have to write about my choice of which controller i use in my application. This is where i get confused, since i havent manually programmed a controller and i thought the ViewModel would behave like a controller in my case. Could this be correct? Can the ViewModel behave like a controller?
A controller can send commands to its associated view to change the view's presentation of the model (e.g., by scrolling through a document). It can also send commands to the model to update the model's state (e.g., editing a document). Model_View_Controller
The viewmodel is a “model of the view” meaning it is an abstraction of the view that also serves in mediating between the view and the model which is the target of the view data bindings. It could be seen as a specialized aspect of what would be a controller (in the MVC pattern) that acts as a converter that changes model information into view information and passes commands from the view into the model. The view model exposes public properties, commands, and abstractions. Model_View_ViewModel
The introduction of MVVMC (MVC + MVVM) is nessesary in cases you would like to drive many similar pairs of View-ViewModel (use cases). You can then introduce controllers. Model_View_ViewModel_Controller
In the simplest case, have the ViewModel implement the "controller" logic. For large applications, I sometimes use an MVVMC pattern which uses a separate controller class. There has been a lot of recent support on the blogosphere for using MVVMC over MVVM.
MVVM is dead, long live MVVMC!
MVMMC – MVVM grows a Controller
I recently started doing web dev in C# and I am confused about MVP pattern with the concept of Domain Driven Design.
I was told by one of the seniors that the application is separated into 5 different layers. The hierachical structure is like this: View, Presenter, Service, Repository, Entity.
Here are my understandings for these different layers:
View: Representation of data that is being delivered to client
Presenter: Codebehind. Handles client's request and sends info to service
Serivce: Business logic layer. Manipulates data.
Repo: Not exactly sure what it does.
Entity: An unique object in the domain, and no two objects are ever the same unless they have the same identity (attributes)
So, are my descriptions correct? Can someone elaborate on that? Also, what does the Repo layer do? Does it handle db transaction?
This might not be purely MVP pattern but it seems like this is the state of the application and I am new to all these concepts. It would be great if someone can explain it to me in simpler terms. Thanks.
There are a flew conflicts in my experience.
View - The actual page that renders data. The code-behind will implement the Interface required for the View.
Presenter - No, not the code-behind. The code-behind will instantiate a Presenter. The code-behind implements the View interface, and instantiates a Presenter (and generally passes itself along), like so:
public class CodeBehindPage : System.Web.UI.Page, IViewInterface {
private Presenter myPresenter;
public CodeBehindPage() {
myPresenter = new Presenter(this); // Presenter will require IViewInterface
}
}
Service - Correct.
Repository - Correct, it handles database transactions (loading/saving/etc).
Entity - Correct. Entities are Database objects.
I don't prefer to combine MVP design pattern with N-Tier Architecture. What you have described is more likely about N-Tier Architecture. N-Tier is an architecture that creates tier between logics.
Mainly there are 3 logics, presentation logic (UI specific logic such as calculating height or width of a control), business logic (data manipulation, validation, etc) and data access (CRUD operation).
MVP design pattern itself only consist of Model, View and Presenter. The view and presenter, in N-Tier architecture is considered as presentation logic. Model is too general in N-Tier, it can include both business logic and data access. MVP are a design where the view is communicating with the code behind via event-driven. As example is Asp.Net and C# Winform. Another good design pattern is MVC which is used in ASP.Net MVC.
Now speaking of your understandings of layers:
View is the UI. In Asp.Net it is .aspx file. It is considered as Presentation Logic Layer in N-Tier
Presenter is the code behind. In Asp.Net it is .aspx.cs file. It is considered as Presentation Logic Layer in N-Tier
Service is good, it is considered as Business Logic Layer in N-Tier
Repository is data access. Its main purpose is to communicate with the data storage. It can be Xml, Flat file, CSV or commonly database. It is considered as Data Access Layer in N-Tier
Entity is an object, which purpose is modelling the data, and will be passed between the layer. There is also a principle of POCO, where your Entity should be made as simple as you can (only consist of Properties). Its main purpose so that your Entities can be used in any kind of layers.
Domain Driven Design itself is another concept. It is a concept of designing the application regarding to the business process requirement. Not based on data which is usually be done by most programmer.
As I've been reading this article: http://www.codeproject.com/Articles/42830/Model-View-Controller-Model-View-Presenter-and-Mod, MVC was explained like this:
In this diagram, View-Model is observer pattern where any changes in Model notify View's Update method to update the states of Views and passing its current state to these Views.
Relation between Views and Controllers are defined in Strategy Pattern where Views get concrete controllers and run the algorithms in controllers as defined by Strategy Pattern.
So Controllers update models and models notifies views to update their states.
However, for some reason I couldn't visualize the same logic for Asp.Net MVC as Controllers have access to Model and pass these models to Views but views uses Models directly to get their properties,etc to update their states but I couldn't fit the observer pattern between Views and Models in Asp.Net MVC.
Could some one please explain what I am missing out?
ASP.NET MVC upholds the stateless nature of the web, so once a view is rendered there is no way for the controller to know about changes to an instance of a model object.
This is different to a stateful platform like Silverlight or WPF. The fact that they're stateful allows a controller (or ViewModel if you're using MVVM) to observe what's happening on the UI, make changes to model objects, and then have the view update itself accordingly.
In ASP.NET MVC when data gets passed from the controller to the view, it's a one-way trip. There's no equivalent of the View.Update() method; the view gets rendered once and then that's it. There's also no way for a view to call back to a controller, as per Controller.AlgorithmInterface. You can achieve something similar with an AJAX callback but then you'll have to use some behind-the-scenes magic to repopulate the controller with the state data (e.g. by passing an object ID from the view back to the controller).