I got a source-code and was trying to understand it using the documentation.
In the documentation, it says that the code has used both MVP and MVVM in combination to make the project.
can someone answer these following questions of mine:-
What is point of using two design pattern in a single project(both MVP and MVVM) ?
How can I simple know by looking at some source code if it is made using mvp,MVC or any other design pattern?
can you tell me about ....what are layers in any design pattern? how many minimum layers are we gonna use to make a project in any design pattern? and what is the benefit of having as many layers as possible?
what is the difference between java logic and android logic? coz we're simply separating apart java from android logic for the better testing environment by using any design pattern. Give example.
If the code is using MVC you will see the following:
Models: Models contain data information. Does not call or use Controller and View. Contains the business logic and ways to represent data. Some of this data, in some form, may be displayed in the view. It can also contain logic to retrieve the data from some source.
Controller: Acts as the connection between view and model. View calls Controller and Controller calls the model. It basically informs the model and/or the view to change as appropriate.
View: Deals with UI part. Interacts with the user.
For MVVM (Model View View Model):
ViewModel:
It is the representation of the state of the view.
It holds the data that’s displayed in the view.
Responds to view events, aka presentation logic.
Calls other functionalities for business logic processing.
Never directly asks the view to display anything.
Now let's see MVP (Model View Presenter):
Similar to traditional MVC but Controller is replaced by Presenter. But the Presenter, unlike Controller is responsible for changing the view as well. The view usually does not call the presenter.
Now your questions:
What is point of using two design pattern in a single project(both MVP and MVVM)?
Ans: It may be the need. Also they both are very closely related and as I said it might be useful to mix the two to solve a particular type of problem.
How can I simple know by looking at some source code if it is made using mvp,MVC or any other design pattern?
Ans: Read the explanation I provided. Try to see which pattern closely matches the code. There might be multiple design patterns used.
can you tell me about ....what are layers in any design pattern? how many minimum layers are we gonna use to make a project in any design pattern? and what is the benefit of having as many layers as possible?
Ans: There are no such hard and fast rule on number of layers. To make your code reusable, maintainable, open for extension and follow the best practices of software engineering it is important that you follow the design patterns.
what is the difference between java logic and android logic? coz we're simply separating apart java from android logic for the better testing environment by using any design pattern. Give example.
Ans: There is no such thing called Java logic and Android logic.
Related
From what I've read until now (this answer precisely), it tends more towards MVVM pattern. Considering the data from services as Model, Angular controllers as VM and the HTML containing angular bindings as the View.
Can we say that MVC is a pattern for server side and MVVM for client side?
Can someone explain with example (in context of Angular) how we can
implement MVC and MVVM.
I've read about the concept of using var vm = this; in Angular controllers. But does it mean by just using an alias for our controller we convert our Angular app from MVC to MVVM.
First I think, It is better to give some idea about MVC and MVVM.
More than describing on much more theoretical context. I'd rather explain with a simple example. Lets take buying a pizza.
MVC - It is something like what happens, when you call the pizza center and get delivered.
You call a Call Center Guy(Controller) and make an order(input).
Then the Call Center Guy(Controller) arranges Some Cooks(Model) to make the pizza, a Delivery Guy(View) to deliver the pizza.
Then Delivery Guy(View) gets the pizza from Cooks(Model), wrap it nicely(output) and deliver to you.
MVVM - More like, what happens, when you go the shop and place your order to the waiter.
You place your order(input) to the Waiter(View).
The Waiter(View) place you order to the Cafe Manager(View Model).
The Cafe Manager(View Model) arranges some Cooks(Model) to make the pizza.
Cooks(Model) makes it ready and pass it to the Cafe Manager(View Model).
Then the Cafe Manager(View Model) puts it into a nice plate, adds forks/knives, sauce dispenser etc. (Presentation).
Waiter(View) keeps track of Cafe Manager(View Model). Once it's ready, then the Waiter(View) delivers to you.
When getting back to your question,
Can we say that MVC is a pattern for server side and MVVM for client
side?
What I can say is Generally Yes. (might have some corner cases). I hope, you can use my above explanation to better deal in depth of your problem.
Addition to that since you are referring about AngularJS, in architecture, it is much close to MVVM (I am telling like that because it is more like there's no answer). Though we have Controllers in AngularJS, actually they exactly do the work of View-Models.
----------Update with AngularJS Specific Example----------
Since I would like to remain our scope inside Angular architecture. I am taking a general example.
You have your HTML template for the component you are going to implement with AngularJS. [View]
That HTML template is bound to a Controller, where inside that you would probably have something like this.controllerAs = vm. Actually this term vm refers to View-Model. [View-Model]
Ideally inside this controller, we should not implement business specific logic. If you want them to be included in the client side, you should have separate Factories, Services (custom) etc. to do that. What you can do is, you can include those (Factories, Services) inside the controller and call their required functions/methods to perform the operation required. Otherwise you can consider having your business logic in the server side and using inbuilt services(Ex: $http) to call them.
So Inside the controller we only have the implementations bound to view logic (display requirements) we want.
So as I mentioned in the second point, you have either your [custom Factories, Services] or [set of REST services + $http], which consists your business logic. [Model]
So inside the communication flow what really happens is,
A client(end user/another component) calls/initiates the HTML(View) preferably with some input.
Then the controller(View-Model) gets the inputs and knows what the required task is.
Then the controller calls the Factories, Services etc. inside the it(Model) to prepare the desired business specific output bound to the given input.
The Model then processes the input and gives the desired output to the controller.
Then the controller makes some display specific adjustments.
Then the HTML will display.
Let's just see a bit about the history of MVVM:
MVVM was originally defined by Microsoft for use with Windows Presentation Foundation (WPF) and Silverlight, having been officially announced in 2005 by John Grossman in a blog post about Avalon (the code-name for WPF). It also found some popularity in the Adobe Flex community as an alternative to simply using MVC.
In recent years, MVVM has been implemented in JavaScript in the form of structural frameworks such as KnockoutJS, Kendo MVVM and Knockback.js, with an overall positive response from the community.
Meanwhile, You are right, AngularJS was closer to MVC (or rather one of its client-side variants), but over time by many refactorings and API improvements, it's now closer to MVVM – the $scope object could be considered the ViewModel that is being decorated by a function that we call a Controller.
The software behaviors that are common to MVC, MVP, and MVVM are:
1)Data Layer / Business Logic (Model): This is the behavior which applies the business logic to the application's data
2) Presentation Layer / UI ( View ): View is responsible for the visual presentation of the application.
3) Application Logic ( Controller, Presentation or View Model ): This behavior holds the logic that implements the interaction between the model and the view.
MVVM
MVVM provides a clear separation between the UI and application logic.
Client-side library:Knockout.js, Kendo (MVVM)
Server-side library: Silverlight ,Windows Phone apps,Adobe Flex or Tanuki which is an MVVM-inspired web framework that fancies idiomatic Ruby, DRY and extensibility by its design, or another example would be The WebCore 3 PHP framework which is a platform-independent framework that uses the MVVM pattern.
So I would say this is not correct to say that a specific pattern is just for Client or Server side, It's totally related to the framework that we are using or probably environment that we are going to establish for our project whether in Front or in Back-end development.
Documentation: Here
Please read this article
Interesting Article for AngularJs MV*
While adding extra functionality to the main view I have in my application, I've realized that the amount of code will soon become a problem (currently around 600 lines of code in my viewmodel and I still have plenty to add).
I've been looking around for articles on how to split/design your view into smaller components, but I haven't found a satisfying solution. One person suggested using child viewmodels but that presented with other problems (dependency between the viewmodels).
I've thought of using user controls, but there is nothing on the View that I use on other Views so it kind of defeats the purpose of user controls.
What is a correct approach in this situation?
Thanks,
Adrian
If you want to split a view into component parts, then you need to do view composition. If you are building an MVVM app, then you should really be using an MVVM framework. Something like Caliburn.Micro makes view composition incredibly easy.
There doesn't necessarily have to be dependencies between the view models, they should only know about what they need in order to produce their view. This could be a subset of the business object that the parent view model contains. As the parent view model will have references to all of the child view models, it can pass the relevant parts of the business object to them at the point of their construction.
I would agree with using Caliburn Micro.
However, to play devil's advocate you could split out your ViewModel File into separate files (same class name) and use the partial keyword before the class keyword. Its generally tidier and one step-away (non-breaking precursor) from breaking-up into separate classes.
I also agree Caliburn.Micro is a good solution for splitting your application in smaller components.
In Caliburn.Micro the communication between viewmodels is based on the Event aggregator pattern.
This makes a loose coupling between viewmodels
Splitting up is not ideal.
It looks as if the Caliburn toolkit focuses on events, whereas my application largely relies on ICommand implementations.
To me, the first encounter with Caliburn.Micro has been unsatisfactory.
The setup appeared to be tailored to VS2010 - which sounded promissing to me - because I do have VS2010 pro. But I got lost in the setup's of Silverlight.
Compared to toolkits like Prism it lacks the ease of an start.
It just takes to much time to switch now.
I use my own MVVM paradigm, it is less abstract than the Caliburn, it integrates multilanguage support everywhere, and it just faces one acceptable problem of some sources getting too big because of the nature of the Binding/DataContext paradigm.
For this problem I accept that "partial class" is a solution - even though I know there is a more elegant solution available.
In the heat of my work, I cannot change to another toolkit.
So I gently wait for Microsoft to allow for more flexibility around that Binding/DataContext paradigm.
It may be the case that Caliburn shows more intelligence allocating a viewmodel to some item. Does it ? (I think it does.)
What might be another option is to define a custom (xaml useable) object that triggers a custom allocator which control is to be allocated to which viewmodel. How about that ?
I'm trying to get up to speed with using WPF and the Prism framework which is heavily associated with the MVVM pattern. I've ready many different descriptions, examples and discussions on MVVM and each one is slightly different and has left me a little confused.
My understand is as follows:
The MVVM pattern has 3 parts to it :-
Model - the classes that hold the application data/information.
View - The visual elements of the application.
ViewModel - The logic, state and other behaviour associated with the visual elements. It takes data from the model and exposes it (possibly with some data conversion/formatting) in such a way that the View can use it directly.
What I'm not sure about is:
Do these 3 parts cover every part of the application? Or can there be parts of the application that are outside these 3 parts?
Is it the ViewModel or some other part that is responsible for populating the Model?
Thanks in advance
Absolutely not. Unless they do. If your application is simple, then everything can be handled in the View, ViewModel or Model(s). If your application is complex, and best practices dictate you break out logic into their own types (communication logic, repository logic, etc), then there is no stopping you. MVVM is only concerned with view-centric logic within the View, application logic within the ViewModel, and the means of storing information for transmission between the two.
The ViewModel is solely tasked with interpreting user actions and readying the results of logic within Models so that the View may display this information to the user. In some cases, it makes sense that a Model itself hold some logic so that it may respond to user actions. However, it has been my experience that this mini-ViewModel-Model design is in reaction to design decisions by inexperienced developers. Once you get the real hang of MVVM, you usually don't have to (or want to) put any code in your Models apart from validation logic.
Think of Model, ViewModel and View as logical layers that handle Business, application flow and presentation respectively. For example, a ViewModel class may delegate complex or reusable UI interactions to a separate service that doesn't correspond to any particular view but still belongs to ViewModel layer.
Yes, ViewModel stands between UI and Model.
I like the concept of REST wherein each page is stateless. However, I haven't seen anyone using it in windows application. Way back, when I'm still using MVC and MVP patterns, one of my setbacks is handling states.
I don't know if this is a good idea, but I like to know your opinion on this. :)
Thanks.
I guess it depends on how you implement this. My view models typically keep state in properties that the views can bind to. However, I have sometimes found it useful to keep that state information in a separate object, which my view model hangs on to. My view can still bind to it and it declutters my view model.
I've built two large winforms apps using REST and I'm starting to experiment with WPF. WPF should be even easier.
I use MVC on the server for my REST resources and MVC on the desktop.
I don't develop too many desktop / Windows Forms applications, but it had occurred to me that there may be some benefit to using the MVC (Model View Controller) pattern for Windows Forms .NET development.
Has anyone implemented MVC in Windows Forms? If so, do you have any tips on the design?
What I've done in the past is use something similar, Model-View-Presenter.
[NOTE: This article used to be available on the web. To see it now, you'll need to download the CHM, and then view the file properties and click Unblock. Then you can open the CHM and find the article. Thanks a million, Microsoft! sigh]
The form is the view, and I have an IView interface for it. All the processing happens in the presenter, which is just a class. The form creates a new presenter, and passes itself as the presenter's IView. This way for testing you can pass in a fake IView instead, and then send commands to it from the presenter and detect the results.
If I were to use a full-fledged Model-View-Controller, I guess I'd do it this way:
The form is the view. It sends commands to the model, raises events which the controller can subscribe to, and subscribes to events from the model.
The controller is a class that subscribes to the view's events and sends commands to the view and to the model.
The model raises events that the view subscribes to.
This would fit with the classic MVC diagram. The biggest disadvantage is that with events, it can be hard to tell who's subscribing to what. The MVP pattern uses methods instead of events (at least the way I've implemented it). When the form/view raises an event (e.g. someButton.Click), the form simply calls a method on the presenter to run the logic for it. The view and model don't have any direct connection at all; they both have to go through the presenter.
Well, actually Windows Forms implements a "free-style" version of MVC, much like some movies implement some crappy "free-style" interpretation of some classic books (Romeo & Juliet come to mind).
I'm not saying Windows Forms' implementation is bad, it's just... different.
If you use Windows Forms and proper OOP techniques, and maybe an ORM like EntitySpaces for your database access, then you could say that:
The ORM/OOP infrastructure is the Model
The Forms are the Views
The event handlers are the Controller
Although having both View and Controller represented by the same object make separating code from representation way more difficult (there's no easy way to plug-in a "GTK+ view" in a class derived from Microsoft.Windows.Forms.Form).
What you can do, if you are careful enough. Is keep your form code completely separate from your controller/model code by only writing GUI related stuff in the event handlers, and all other business logic in a separate class. In that case, if you ever wanted to use GTK+ to write another View layer, you would only need to rewrite the GUI code.
Windows Forms isn't designed from the ground up to use MVC. You have two options.
First, you can roll your own implementation of MVC.
Second, you can use an MVC framework designed for Windows Forms.
The first is simple to start doing, but the further in you get, the more complex it is. I'd suggest looking for a good, preexisting and well-tested, MVC framework designed to work with Windows Forms. I believe this blog post is a decent starting point.
For anybody starting out, I'd suggest skipping Windows Forms and developing against WPF, if you have the option. It's a much better framework for creating the UI. There are many MVC frameworks being developed for WPF, including this one and that one.
According to Microsoft, the UIP Application Block mentioned by #jasonbunting is "archived." Instead, look at the Smart Client Application Block or the even newer Smart Client Software Factory, which supports both WinForms and WPF SmartParts.
Check into the User Interface Process (UIP) Application Block. I don't know much about it but looked at it a few years ago. There may be newer versions, check around.
"The UIP Application Block is based on the model-view-controller (MVC) pattern."
Take a look at the MS Patterns and Practices Smart Client application block which has some guidance and classes which walk you through implementing a model view presenter patter in windows forms - take a look at the reference application included.
For WPF this is being superseced by the prism project
The software factories approach is a great way to learn best practices