I have a meta model in Enterprise Architect. The project folder has one main <<Component>> which is the System. This System has many children with stereotype <<Application>>. Application means any component which is part of the system. Each of these components have services (provided and/or consumed interfaces).
My question is, I want to add a resource or object to these service. Could somebody guide me how to do this. The only option I can find is to add ports.
Apologies for not providing too much specifics, as the project is non disclosable.
EDIT: I can give an example. Suppose the system is a Car and one of the applications is Navigation System. The Navigation System has a service called Navigation (providedInterface that provides Navigation). I want to add children to this service, like say Notification, Audio Feedback, etc. These objects (or called as resources in my project) have different properties like getCurrentLocation, showRemainingDistance, etc.
Related
I'm building a WPF application using MVVM pattern, and Caliburn.Micro is the framework choice to boost up the development.
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer to handle logic for specific business cases. VM is left with data binding and simple conversion/presentation logic. Below BL is an extra Data Access layer (DAL) that encapsulates the Data model (DM) underneath built with Entity Framework.
I'm pretty new to both WPF, MVVM and, of course, know almost nothing about Caliburn. I have read plenty of questions and answers about the Caliburn usage and now trying to use what I've learnt so far in my application.
My questions are:
Does it sound okay with the above layered architecture?
In the application bootstrapper, is it correct that we can register all services that will later be used (like EventAgreggator (EA), WindowManager or extra security and validation services), and also all the concerned VMs? These should be injected into VM instances via constructors or so (supposed I'll be using SimpleContainer). So from any VM that are properly designed and instantiated, we can have these services ready to be used. If I understand correctly, Caliburn and its IoC maintain a kind of global state so that different VMs can use and share it.
Navigation: I know this topic has been discussed so many times. But just to be sure I'm doing the right way: There'd be a ShellViewModel acting as the main window for the whole application with different VMs (or screens) loaded dynamically. Each VM can inherit either Screen or ViewModelBase or NotifyChangedBase. When I'm in, let's say, VM A and want to switch to VM B. I'd from inside VM A send a message (using EA) to the ShellViewModel, saying that I want to change to B. ShellViewModel receives the message and reloads its CurrentViewModel property. What should be a proper data structure to maintain the list of VMs to be loaded? How can stuffs like Conductor or WindowManger come into the place?
Can/Should Caliburn in one way or another support the access to the database (via EF). Or this access should be exposed to VM and/or BL only?
Thanks a lot!
Different from a conventional MVVM-based application, I add a business layer (BL) below the ViewModel (VM) layer
That's the standard case. ViewModels can't/shouldn't contain business logic which is considered to be part of the Model (Model in MVVM is considered a layer, not an object or data structure) in the MVVM. ViewModel is for presentation logic only.
Yes, as long as your Business (Domain) Layer has no dependency on the DAL (no reference to it's assembly). Repository interfaces should be defined in the Business Layer, their implementations in the Data Access Layer.
Yes, Bootstrapper is where you build your object graph (configuration the IoC container).
Registering ViewModels: Depends on IoC framework. Some frameworks let you resolve unregistered types, as long as they are not abstract or interfaces (i.e. Unity). Not sure about Caliburn, haven't used it. If the IoC supports it, you don't need to register them.
One possible way to do it. I prefer navigation services though, works better for passing around parameters to views and windows that are not yet instantiated and you always know there is exactly one objects handling it.
With messages, there could be 0, 1 or many objects listening to it. Up to you
What do you mean with support access to the database? You can use it to inject your repositories and/or services into your ViewModels, other than that there isn't much DB related stuff to it.
How can I manipulate other modules without editing them ? very the same thing that wordpress modules do .
They add functionality to core system without changing the core code and they work together like a charm.
I always wanted to know how to implement this in my own modular application
A long time ago I wrote the blog post "Use 3rd party modules in Zend Framework 2" specifically about extending Zend Framework 2 modules. The answer from Bez is technically correct, it could be a bit more specific about the framework.
Read the full post at https://juriansluiman.nl/article/117/use-3rd-party-modules-in-zend-framework-2, but it gives you a clue about:
Changing a route from a module (say, you want to have the url /account/login instead of /user/login)
Overriding a view script, so you can completely modify the page's rendering
Changing a form object, so you could add new form fields or mark some required field as not required anymore.
This is a long topic, but here is a short gist.
Extensibility in Zend Framework 2 heavily relies on the premise that components can be interchanged, added, and/or substituted.
Read up on SOLID principles: http://en.wikipedia.org/wiki/SOLID_(object-oriented_design)
Modules typically consists of objects working together as a well-oiled machinery, designed to accomplish one thing or a bunch of related things, whatever that may be. These objects are called services, and managed by the service locator/service manager.
A big part of making your module truly extensible is to expect your developers to extend a class or implement a certain interface, which the developer register as services. You should provide a mode of definition wherein the developers can specify which things he wants to substitute, and/or add their own services to -- and this is where the application configuration comes in.
Given the application configuration, you should construct your machinery a.k.a. module services according to options the developer has specified i.e., use the developer defined Foo\Bar\UserService service as the YourModule\UserServiceInterface within your module, etc. (This is usually delegated to service factories, which has the opportunity to read the application configuration, and constructs the appropriate object given a particular set of configuration values.)
EDIT:
To add, a lot can be accomplished by leveraging Zend's Zend\EventManager component. This allows you to give developers the freedom to hook and listen to certain operations of your module and act accordingly (See: http://en.wikipedia.org/wiki/Observer_pattern)
I have great experience in programming by using java and other languages.
I need anyone who has great experience in using GWT with MVP to explain how to build GWT Application using MVP:
View package : explain what should be in view class.
Client Package: explain what java files are supposed to be here and what is the benefit from each file.
Server Package: I think here all services files( RPC ).
Activity Package: Explain what is the benefit from the classes here , I think here we we connect events with controls in view classes( Am I correct?).
Place Package: I need to understand this very well.
Also what is the benefit from Clientfactory java file?
what is eventbus?
what is placecontroller?
please if you can order which file should be coded one after another?
Thank you in advance,
1) View is a widget with link to its presenter. It should notify presenter about ui events which should be processed.
2) Views, presenters, client(not shared with the server side) model, places, activities, PlaceHistoryMapper, ActivityMapper. About benefits see below.
Are you understand presenters well? According to your question i assume you confuse it with activities.
1.1 ) Presenter creates and manages view, makes rpc and most of 'logic' stuff.
3) You are right, server package is just a java server logic.
4) Activities link places and presenters. I will return to describing activities below.
5) Place has name, token and own Tokenizer which transforms its place to a token and other way round.
6) I didn't use ClientFactory. I prefer dependency injection with google-gin(gwt client version of guice)
7) Event bus is... I couldn't describe better than official javadoc does :)
Dispatches Events to interested parties. Eases decoupling by allowing objects to interact without having direct dependencies upon one another, and without requiring event sources to deal with maintaining handler lists. There will typically be one EventBus per application, broadcasting events that may be of general interest.
8) PlaceController knows where you are(in application :) and may change current place. (obviously, it has getWhere() and goTo(Place) methods)
9) Firstly you need to code application's singletones like PlaceHostoryMapper and ActivityMapper.
PlaceHostoryMapper provides history and converting tokens to places by segregating all PlaceTokenizers.
ACtivityMapper segregates all places and activities and provides second ones by first ones.
Views and presenters are based on interfaces. Next I would declare such interfaces.
Then write places. Then you able to code activities because you have places and interfaces of presenters.
Then in any order implement views and presenters, map activities to places in ActivityMapper and register PlaceTokenizers in PlaceHistoryMapper.
I assume now you have more questions, feel free to ask in comments or by contacts in my profile :)
I'm about to develop this small website, its basically a simple web app to store informations about patients for a doctor.
The company i have got the assignment from demands an introducton with a class diagram, honstly, i have done this already but only for standalone apps, i'm very new in designing class diagrams for websites.
What i'm using is the Ivar Jacobson's iterative metho with usecases, where a usecase includes:
Actors, scenario (representing user-system interactions when all goes fine), and worse case scenatio (solutions when something goes wrong).
By applying this i came to a good conclusion, a well prepared class diagram.
My problem is that i'm doubting whether or not i should include jsp views and servlets(in my case action beans since i use Stripes) in the diagram, i mean, the bridge between the business-classes and the user are the jsp-views and the provided info are going to be processed by the servlets (or action beans), would you include them in the class diagram?
For a small project tis might be not that relevant but what if you have a project with 30 views and 20 servlets, the diagram would become messy and huge.
Do you have some tips about it?
Thank you
If the only reason you need the class diagram is to satisfy the client, best find out what they're looking for first.
If however they're not specific (and ignoring the cynical options) I'd suggest the following:
Create a "Domain Model" diagram. i.e. capture the concepts in the domain and their inter-relationships. So Doctor, Patients and associated stuff.
Don't create a "design" class diagram - i.e. no jsps, servlets, etc. If necessary create a simple architecture picture instead showing how the application is layered.
Rationale: a domain model is good for checking scope and verifying domain rules (relationships). A "design" class diagram only obfuscates that. A proliferation of jsps, controllers, etc. hides the underlying architecture pattern while distracting from the useful stuff in the domain model.
hth.
I'm starting a new project which in simple terms will have a UI layer based on asp.net mvc 2, a business layer and a data access layer. Simple 3-tier design.
The UI layer though will be customized for the client, e.g. menus along the top, or down the left or maybe different static pages, etc.
All the core features will be the same across the multiple clients but some clients may have more or less features available to them.
I'm thinking of using Areas in one single asp.net mvc project to separate the clients. So as I add clients I will add areas - is this a good approach? If I follow this approach can I share controllers? but have the controller route to the correct view within the area?
Also if I deploy my site to mynewsite.com - each area is going to be accessible at mynewsite.com/area1, mynewsite.com/area2 and so on. But if a client would like their own domain, what is the best way of achieving this? so that www.clientdomain.com -> mynewsite.com/area1 and clientdomain.com/products/list is the same as mynewsite.com/area1/products/list - would I have to handle this through the HTTP Url Routing on the server?
Hopefully I've explained my situation ok! Many thanks for any feedback.
Just for information - I decided against using areas in the end and I have simple client configuration component with custom view engine that I put together to swap out the views per client (using domain name and/or when the user logs in). The views are currently held in client specific folders and I only put the views I need to change for a client into those folders, if the view engine cannot find the view in the client specific folder it will revert back to the default views, which is pretty much the normal case as 90% of the client specific changes are done with CSS.