I need to convert the following AngularJS application to a GWT application (though the question applies to any angular application). I would like to use the MVC pattern and UiBinder as suggested in the documentation but I'm unsure as to how the components of the angular application should correspond to the GWT one.
I've given it some thought already and here's my understanding - I'd be grateful if someone could say if I've got it right
Each module should become a presenter
One view per presenter
Services must be initialised in the AppController and passed to the relevant presenters (similarly to how an eventBus is implemented in the MVC description)
Now I don't know how to put multiple presenters together, though, so that they create one page. Should I create a main view that would correspond to the AppController and then pass the relevant parts of that view to each presenter?
Also, what's the best way to handle modal dialogs? Should I just include them in the view, bind to the presenter and keep them hidden initially?
I would recommend to use either Activities and Places or a fully fledged MVP framework like GWTP.
Regarding your questions:
I think that's right
One view per presenter is the usual approach. However you can also think of implementing different views for different devices (Desktop, Mobile, etc).
I would recommend to use a dependency injection framework like GIN to inject services and components into your Presenters
It depends if you use Activities and Places or GWTP. GWTP has the conecept of PresenterWidget that can be nested in Presenters. For Activities and Places you can follow Thomas Broyer's recommendation.
In general I think Presenters and their corresponding Views should be standalone components that are usually associated with a Place. GWTP has the concept of Slots (i.e. side navigation, etc) where Presenters can reveal themselves.
Communication between Presenters should be done via the EventBus.
GWTP has a concept of PopupPresenters but typically I think modal dialogs should be included in the View and handled by the parent Presenter (unless it contains a lot of business logic).
You said:
Each module should become a presenter
look at [GWT Organize Projects][1]http://www.gwtproject.org/doc/latest/DevGuideOrganizingProjects.html
It talks about modules in the section, "Modules: Units of Configuration"
Basically, a module is just for configuration. You need a module for each entry point. People often have 1 module per page.
You said:
One view per presenter
This is usually the case.
You said:
Services must be initialized in the AppController and passed to the relevant presenters (similarly to how an eventBus is implemented in the MVC description)
Like Ümit said you should use Gin
Ümit recommended GWTP I'm no expert on GWTP but I used it briefly when I was a beginner and it was hard. I don't think it's good for beginners. Admittedly, it might be worth the investment of learning it. Like I said I'm no expert on GWTP.
Related
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.
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*
I am building a website based on widgets. I have a general WidgetInstancesController class with several methods, a model and some views for it. Now, I want to know if it's possible to extend this class. In other words, each widget should be another class, extending the WidgetInstancesController class. I want to store these widgets classes under app/widgets/. Also, these widgets won't have any specific model (as they will use the parent WidgetInstance model) but may have some specific views.
Any suggestions on how can I do this will be highly appreciated!
I would suggest building them as components, but it can be done in other ways.
I have had to do something similar where I built a CMS with add-on modules. To make it work logically, I had to turn MVC on its head a little and go for a very thin controller. Essentially, the front-end module logic was contained entirely at the Model level, with the associated views as elements. A module helper fetched and displayed the module in the public front-end. The back-end was handled conventionally via MVC with a normal fatness controller.
As it turned out, the Models were surprisingly lightweight and having everything as elements made usability a dream.
I have an app that has several modules that have completely different functionality and I'm trying to figure out the best way to implement this using prism.
To try and better explain, I'll try to use Northwind as an example. I have 3 modules, orders, customers & employees.
The customer module will allow you to do anything pertaining to a customer. Add, remove and edit. I'm going to use scope regions for the main view in the customer module to handle all the different views I need to show here.
In the scenario above, I only want to load a module when a user wants to work with say a customer, order or employee.
You have these modules laid out and realize that you need to be able to show Orders for customer or sales people which are obviously employees.
What would you do here in this scenario as you wouldn't want to create an entirely new modules for say employeeOrders and customerOrders and you wouldn't want to duplicate any order related code.
I'm starting to wonder if it's feasible to think about building a composite application using prism if you're building an app like Outlook, but for a LOB business app, I've yet to find a good sample of how to do this and not break some of the principles of MVVM and definitions of Prism in order to do so.
I'm just 3 weeks into Prism and still learning but this is the biggest issue I'm running into.
Any thoughts?
You should be using the Event Aggregator for these types of communication scenarios. Essentially, you want a module to provide functionality but also expose events that can be invoked from other modules. You can also register a service in the Unity container. For example:
public interface ICustomerOrderInvoker
{
void DisplayCustomerOrdersInRegion(string customerId, string regionName);
}
These techniques are somewhat orthogonal to MVVM. Your event handler can create a view/viewmodel pair and insert them into a region. Or your event handler can create a UserControl with all functionality implemented in code behind and adds it to a region. The beauty of the composite UI is that your modules can use MVVM and another team's modules can use straight forward user controls or MVP or MVC or anything really; the point is that all the modules are composed into one application regardless of how they are implemented because they use the patterns established in Prism like regions, events, etc.
In your particular case:
You have these modules laid out and realize that you need to be able to show Orders for customer or sales people which are obviously employees.
Your Order module will certainly be aware of the concept of a customer id since the Order entity is associated with a customer. The Order module should expose an CompositePresentationEvent that displays a view that has all the orders for a particular customer id.
The point of Prism is to create logically separate and loosely coupled pieces of functionality. This does not mean that the modules do not communicate with each other, but rather that the communication happens in a limited and loosely coupled manner. You can certainly write LOB applications using this pattern and MVVM; many of us have been for years now. :)
Im working on a similar problem (and am new to Prism too), as yet don't have a solution. I think when using Prism its tempting to use the framework as the reference implementation intends, but it doesn't need to be so.
Prism should (when used correctly) facilitate software development, not hinder it. So don't get too stuck in the idea that any implementation must meet strict decoupled refactorised super patternised standards!
What I am doing/intending to do is create a MainModule, which has in it much of my core functionality, including a MainView/MainViewModel user control. The Shell then has one region "Main" and on MainModule load the MainView is injected into it as per standard prism usage.
I'm using a Docking Manager from Telerik (compatible with Silverlight and WPF) on the MainView and have implemented a class IDockingManager / DockingManager class in Infrastructure which is registered with Unity as a singleton (ContainerControlledLifetimeManager) in the bootstrapper.
Anywhere in my app I can get the IDockingManager instance and inject a view by calling IDockingManager.DockView(IView view, DockingParameters args). The DockingParameters can contain information such as where to dock (Left, right, top, bottom, tabbed document) and also the parent container to dock in.
This is the part I've not got to yet - I can dock left/right/top/bottom on the main view but I want to implement an attached property or something on my child views registering them as a DockSite when docked. So for instance I could dock a Treeview on the left and dock underneath that a listview by using the Treeview name as parent DockSite and DockBottom as the side.
Hope that makes sense, I've rambled without really explaining too well. Basically what Im saying is Im not using regions at all (except to inject the MainView) in this application and have created a class to handle view injection into dockable containers. It's not strictly Prism but Prism is there to make my life easier, not the other way around ;)
I would like to use Ninject in my WinForms application. I cannot figure out how to use it for my user controls. Sometimes they rely on the services I want to configure through the DI framework. These controls need to be manageable through the designer (thus need default constructors).
So, is there a way to inject dependencies into properties of this user control? Since the designer needs to be able to construct it, kernel.Get<TestClass> won't work here. Is there a method or some code that will let me "fill-in" the dependencies in the Form_OnLoad() method?
I can also think of other examples where I would want to Inject into the properties of an already existing object, but th WinForms user control is the easiest to explain.
I think you need to invert your thinking. In Model View Controller, the View has only one responsibility: to display data.
How that data gets there is the Controller's responsibility, and how the data is represented in memory is determined by the Model.
Although there are no specific MVC frameworks for Windows Forms, it's possible to make crude ones manually, or you could go have a look at the (now retired) Composite Application Block to get an idea about how this can be done (although the CAB is perhaps too complicated for most people's tastes). There are more elegant options available today, but they involve WPF.
In any case, instead of injecting your dependencies into your Views, inject them into Controllers, and have the Controllers instantiate and correctly populate the Views (your Controls).
In this way, you can keep your Controls free of DI concerns, as they should be.
I think the question is what DI tool can you use to get dependency injection to work with windows forms. Everyone does the MVC example because it's easy to implement(the same example if floating around the we as if it were new and original). If you have an answer for doing it using winforms or even WPF - that would be helpful.
This answer here basically says - in any case, I don't know so inject them into controllers and populate the views - really? Back to the MVC? Again - winforms.