I have designed and developed my application in MVP Pattern. I have not used any software factory to achieve this. Now i want to shift to SCSF pattern and CAB structure.
I need to know if it can be done in any easier way as CAB structure implements MVP only.
I would agree with Wali. you have got your views ready . Assuming they are in perfect MVP. now you need to classify them into Modules.
We created child workitems, so that when a use case is started it was a new instance of child workitem added to the workitems collection of the module. So when the use case is completed we simply terminated the child workitem. If any exception occurs then the childworkitem is the one going to be affected now the Module's work item.
SCSF has feature where you can compose multiple views on the screen. So you need to look out if you can use ZoneWorkspace to avoid duplicate UI and logic.
Decide how the modules are going to communicate, say events or Commands.
How data is going to be passed between views and modules. Now you have the Shell, you need to decide what all regions you are going to have on the shell. What comes by default on the shell. How the modules listen to Shell. What events Shell listen from modules to customize itself.
SCSF has dependency injection. So decide what are the UI Services you are going to have. Inject them in to Presenter accordingly.
In CAB and SCSF, there is code-ready MVP classes (and interfaces). So if you have implemented it cleanly, then you can just copy your methods once you get a hang of the classes.
Will try to brief it :-
1) IView -- Its a reference of View, which exposes only those set properties/Methods which can be accessed by Presenter (or any other class)
2) View -- It has a reference of Presenter and can access all the public/protected methods of presenter. By design it cannot access any service, as you would require WorkItem (container of Services, State, Command, Events Etc). For all practical purpose View is only there to manage the UI controls, Binding, State of object Etc.
3) Presenter -- It has a reference to WorkItem (through which you can access all the services). Presenter's responsibility it to manipulate data with the help of Services.
4) WorkItemController -- WorkItemController can take UseCase related functionality as in wiring/unwiring of ui controls, positioning of view etc.
Its more than just MVP in SCSF/CAB as its overall design of a UI Application. Which has the following :-
Modular Structure
On-Demand architecture.
Service Pattern
Commands
Event Handlers
Etc.
So firstly you have to check codeplex docs to see if your project would be easily upgraded in that platform/architecture. I would recommend CAB/SCSF if you have just begun and thinking of making the project scalable and enterprise level.
Related
We have an ERP solution, which had lot of modules. As a product company we are having several clients.
The source control is maintained in TFS.
Now we customization for reach clients, what is the best way to manage the source code?
Truly I believe this depends on the language the application is built with:
MVC
In general, hopefully the business logic of all the applications is remaining the same, in that way the only differences would be in the view of each new instance. To manage these different views I would create sub-folders for each product. But once again this is very generic as we don't know much about the current infrastructure.
Edit
Generally Speaking the branching stragey described here will work for most cases: https://stackoverflow.com/a/20878555/5268586. For your application, if you are changing core logic located inside your application consider extending a base class for each client and overriding it's functionality to handle the new clients calculations.
i.e.
you have a class/file called CalcEngine
your client want to change some calculations, so make a new class Client1CalcEngine that will implement all of CalcEngine and override the one method/function. These customer focused classes can then be bundled in your normal branches, as the implementation logic will decypther which to use.
I am learning Mac OS X development, and from reading different articles and Aaron Hillegass' book, it seems that MVC is the recommended design pattern to be used in Mac-based apps.
However, I could not find any instruction as to how when should we introduce a controller class/object and how many we should use.
So my question is:
Do we normally have one, or more than one, controller classes in a Cocoa-based Mac OS X app?
If we have more than one, what is the criteria for introducing a new controller class? How do the controller classes interact among themselves, or do they not and there is no need for such interaction?
This is partly a matter of making the application easy to understand, keeping the code organized, and somewhat a matter of personal taste.
A simple application like AddressBook.app could get away with a single controller-layer object. This object could manage the user's interaction with people and groups. Then again, it might have a Person controller and a Group controller, each of which will coordinate interaction between their respective pieces of UI (Group UI to Group controller, etc.) and the data containers (the list of groups and the list of people and, when viewing groups, the list of people that belong to that group). If you're bothering to go this far, you might have a window controller in which to stash the code that isn't specific to groups or people. That is, perhaps the code that manages reconfiguring the UI between Group and Person mode would go in the window controller of the window that contains this UI.
A complex application might have MANY controllers. It may have a controller for each window, the windows may own controllers for each instance of a self-contained set of controls dedicated to one aspect of the application. It may have controllers to manage non-UI items as well (network connections/downloads, user session, physical state of an attached peripheral, etc.). It really truly depends on your application and design needs.
Application architecture is an under-emphasized aspect of software development. Choosing and maintaining a good architecture over the lifetime of an application can sometimes mean the difference between "we can add this feature in a day" and "we'll have to completely rewrite some/half/most of the app to be able to add anything like this feature". It's part science and part art and simply takes experience (and an eye kept open to the architecture of your favorite open source projects as examples).
A critical thing to remember is this: The controller layer is the layer most specific to your app (and usually the least reusable part - purposefully-reusable controllers like NSArrayController not withstanding). It's what makes your app your app. Its model may be reusable to other apps and its views as well, but the controller layer is the "soul" of your app.
I hope this helps.
I've been using MVC for a long time and heard about the "Service" layer (for example in Java web project) and I've been wondering if that is a real architectural pattern given I can't find a lot of information about it.
The idea of MVCS is to have a Service layer between the controller and the model, to encapsulate all the business logic that could be in the controller. That way, the controllers are just there to forward and control the execution. And you can call a Service in many controllers (for example, a website and a webservice), without duplicating code.
The service layer can be interpreted a lot of ways, but it's usually where you have your core business processing logic, and sits below your MVC architecture, but above your data access architecture.
For example, you layer of a complete system may look like this:
View Layer: Your MVC framework & code of choice
Service Layer: Your Controller will call this layer's objects to get or update Models, or other requests.
Data Access Objects: These are abstractions that your service layer will call to get/update the data it needs. This layer will generally either call a Database or some other system (eg: LDAP server, web service, or NoSql-type DB)
The service layer would then be responsible for:
Retrieving and creating your 'Model' from various data sources (or data access objects).
Updating values across various repositories/resources.
Performing application-specific logic and manipulations, etc.
The Model you use in your MVC may or may not come from your services. You may want to take the results your service gives you and manipulate them into a model that's more specific to your medium (eg: a web page).
I had been thinking of this pattern myself without seeing any reference to this any where else and searched Google and found your Question here :)
Even today there is not much any body talking about or posting about the
View-Controller Service Pattern.
Thought to let you know other are thinking the same and the image above is how I view how it should be.
Currently I am using it in a project I am working on now.
I have it in Modules with each layers in the image above with in it's own self contained Module.
The Services layer is the "connector" "middleman" "server side Controller" in that what the "client" side Controller does for the client, the "Service" does for the server.
In other words the Client side "Controller" only "talks" with the "Service" aka Server Side Controller.
Controller ---> Requests and Receive from the <----- Service Layer
The Service layer fetches or give information to the layers on the server side that needs it.
By itself the Service does not do anything but connect the server layers with what they need.
Here is a code sample:
I have been using the MVCS pattern for years and I didn't know anyone else did as I couldn't find any solid info on the web. I started using it instinctively if you like and it's never let me down for Laravel projects. I'd say it's a very maintainable solution to mid sized projects, especially when working in an agile environment where business logic changes on the constant. Having that separation of concern is very handy.
Saying this, I found the service layer to be unnecessary for small projects or prototypes and what not. I've made the mistake of over complicating the project when making prototypes and it just ultimately means it takes longer to get your idea out. If you're serious about maintaining the project in the mid term then MVCS is a perfect solution IMO.
I'm working for a while with silverlight and MVVM (in its simplest form, it's to say hand-made), but I barely understand what is an event aggregator (and how to make an implementation of this).
What is hidding behind this name?
Can someone explain this quickly (or post a link?).
An event aggregator is generally a broker object that you can take a reference to and specify what type of events you want to receive, without having to take a reference or even be aware of the objects generating the events.
Prism's EventAggregator is the most common one. See: http://msdn.microsoft.com/en-us/library/ff649187.aspx
It describes itself as:
The EventAggregator service is
primarily a container for events that
allow decoupling of publishers and
subscribers so they can evolve
independently. This decoupling is
useful in modularized applications
because new modules can be added that
respond to events defined by the shell
or, more likely, other modules.
Pattern of pub-sub events is that the
publisher should not know or care if
there are any subscribers out there,
nor should it care what the
subscribers do if they are there (from
Brian Noyes'
blog)
What are the best practices to using EventAggregator in Prism? Currently I have few modules which are loosely coupled and work independently. These modules use EventAggregator to communicate to other modules. As the application grows I'm confused on how to document my code. There could be many modules publishing Events and many others subscribing to it as Brian puts neither of them knows what other does exactly. When creating a new module how do I make sure they are subscribed to some XYZ event without breaking the loosely coupled structure?
How do I represent a module using EventAggregator visually (some kind of diagrams)?
You have a lot of questions in your post that can be answered "it depends on your application," but I'll try to answer some of them.
One thing that I see most often with EventAggregator is abuse. Many people use EventAggregator in a way that makes both the publisher and subscriber dependent on each other. This brings me to my first bit of advise:
Never assume there are any subscibers to an event.
EventAggregator is useful for publishing events other views might be interested in. For example, in our application we allow a user to change someone's name. This name might be displayed on other views already open in the application (we have a tabbed UI). Our use case was we wanted to have those UIs update when the name was changed, so we published a "UserDataChanged" event so that open views could subscribe and refresh their data appropriately, but if no views that were open were interested in this data, no subscribers were notified.
Favor .NET Events over EventAggregator events where appropriate
Another mistake I see frequently is a business process that is implemented using EventAggregator where data is sent to a central party and then that party replies, all using EventAggregator. This is leads to some side-effects you'd likely want to avoid.
A variation on that I see a lot is communication from a parent view to a sub-view, or vice-versa. Something like "TreeItemChecked" or "ListViewItemSelected". This is a situation where traditional .NET Events would be used, but an author decided that if they have a hammer (EventAggregator), everything (Events) looks like a nail.
You asked about modeling the EventAggregator and I would say this: the EventAggregator is only special in that it allows for decoupling and doesn't create strong references to events (avoiding memory leaks, etc). Other than that, it's really just a very slight variation of the Observer Pattern. However you are modeling Observers is how you would model the EventAggregator in whatever type of diagram you are trying to create.
As to your question about making sure some module or another is subscribed to an event: you don't. If you need to ensure there are subscribers, you should not use the EventAggregator. In these cases I would recommend a service running in your application that modules can grab from your container and use or other similar thing.
The thing to keep in mind about your modules is that you should be able to completely remove one and the rest of your application functions normally. If this is not the case, you either have a module dependency (best to be avoided, but understandable), or dependent modules should be combined into one.