I've gone through a lot of intro-level tutorials on MVVM and can certainly see its merits but I'm having a hard time applying it to my LOB application. I plan on using MVVM Light, though I don't think that's going to impact the overall design structure of my VMs.
Suppose I want to write a TaxiDispatcher application where I have a service that goes out every minute and fetches the latest status of each of my taxis. I also have a list of fixed locations that people can call from and request a taxi. The dispatcher would then assign an available taxi to that location. At any given time, each taxi would either be available to the dispatcher or assigned to one of the particular locations in order to pick up a customer.
My main screen (let's call it DispatcherView) would consist of a list of available taxis on the left-side of the screen and then two additional pieces of visual content: a list of my locations (whether or not a person is there requesting service, which taxi has been assigned to that location, etc..) and a list of taxi assignments (elapsed time since they've been assigned, location, etc..).
All 3 of those views work off the same 2 sources: the taxi data service and the list of my locations that I can dispatch a taxi to. Right now, I've got separate views and view models for each of the 3 views (UnassignedTaxisVM, DispatchLocationsVM and AssignedTaxisVM), each being injected with one, or both, of the data sources. When the dispatcher assigns a taxi from the unassigned list, I use a Messenger to communicate with the other VMs to let them know that the taxi has been assigned to a location (the DispatchLocationsView and AssignedTaxisView are both updated with this new information as a result). But when I'm wiring up each VM, I'm having to inject the same datasource(s) to each of my VMs and thus having to write similar code in each VM to respond to the command when the dispatcher assigns a taxi to a location. It may just be my lack of experience with the framework but it just smells bad to me.
Does it make more sense to simply have one VM (DispatcherVM), and have the DispatcherView be responsible for rendering all 3 pieces of visual content? I envision this would involve having 3 ObservableCollections (UnassignedTaxis, Locations, AssignedTaxis) in my DispatcherVM and binding the datasource of each of the sub-views. As new data comes in from my taxi data service, I'd parse/update to the appropriate ObservableCollection and have my views respond that way.
What's the best practice here? I've got 3 distinct, but similar, "views" of the same underlying data. Should I create seperate VMs for each of the views or have one VM expose a view that essnentially consists of 3 separate lists/datagrids, etc..?
It sounds like you have reusable plumbing across ViewModels. Have you considered using inheritance (i.g. a ViewModelBase class) to reuse that plumbing? If inheritance isn't right for your solution, you could go the route of one main VM that is composed of child ViewModels that the main ViewModel coordinates.
Both patterns are equally good solutions at a high level in my opinion. It's hard to know which is more appropriate without a lot of context.
Related
Say, I have System1 that connect to System 2 through the adapter-microservice between them.
System1 -> rest-calls --> Adapter (converts request-response + some extra logic, like validation) -> System2
System1 is more like a monolith, exists for many countries (but it may change).
Question is: From the perspective of MicroService architecture and deployment, should the Adapter be one per country. Say Adapter-Uk, Adappter-AU, etc. Or it should be just the Adapter that could handle many countries at the same time?
I mean:
To have a single system/adapter-service :
Advantage: is having one code-base in or place, the adaptive code-logic between countries in 90 % are the same. Easy to introduce new changes.
Disadvantage: once we deploy the system, and there is a bug, it could affect many countries at the same time. Not safe.
To have a separate system:
Disadvantage: once some generic change has been introduced to one system, then it should be "copy-pasted" for all other countries/services. Repetitive, not smart.. work, from developer point of view.
Advantage:
Safer to change/deploy.
Q: what is a preferable way from the point of view of microservice architecture?
I would suggest the following:
the adapter covers all countries in order to maintain single codebase and improve code reusability
unit and/or integration tests to cope with the bugs
spawn multiple identical instances of the adapter with load balancer in front
Since Prabhat Mishra asked in the comment.
After two years.. (took some time to understand what I have asked.)
Back then, for me was quite critical to have a resilient system, i.e. if I change a code in one adapter I did not want all my countries to go down (it is SAP enterprise system, millions clients). I wanted only once country to go down (still million clients, but fewer millions :)).
So, for this case: i would create many adapters one per country, BUT, I would use some code-generated common solution to create them, like common jar - so I would would not repeat my infrastructure or communication layers. Like scaffolding thing.
country-adapter new "country-1"
add some country specific code (not changing any generated one (less code to repeat, less to support))
Otherwise, if you feel safe (like code reviewing your change, making sure you do not change other countries code), then 1 adapter is Ok.
Another solution, is to start with 1 adapter, and split to more if it is critical (feeling not safe about the potential damage / cost if fails).
In general, seems, all boils down to the same problem, which is: WHEN to split "monolith" to pieces. The answer is always: when it causes problems to be as big as it is. But, if you know your system well, you know in advance that WHEN is now (or not).
I have the following problem to resolv. Given the following UML diagram:
I need to complete the diagram doing the following steps:
a) When an employee has a skill, the relationship between the employee and the skill shows years of experience.
b) A worker may have another employee as a manager and a worker who is a manager must manage five or more workers. As a manager, you can determine which workers he manages, but a worker can not determine who is his manager.
c) An activity can have a maximum activity precedent and any number of upcoming activities. Using these roles, we can show how the activities are arranged. Given an activity, you can only determine their own activities (if you have), but not what your previous activity (if any).
d) A worker is not simply associated with a set of skills, but a worker has skills. In particular, every worker should have three or more skills, and any number of employees can have the same ability.
e) A project is not simply a set of activities associated with, but contains a project activities. Specifically, a project must have one or more activities, and activity must belong to exactly one project.
f) Projects and activities are a specific type of job.
My solution is shown in the following picture, but because I am new in this I would like to check if is fine.
Thank you in advance!
Looks good in most parts. Honestly I don't understand the later parts of c)
Your -boss relation is wrong. Your Northern Koreans should not have a private known boss. Instead there's only the other way around and the boss has - let's call them - -slaves. If you put in a private -boss it actually means that the slave can navigate to its private boss which is explicitly not wanted. Only the boss shall know the one he's responsible for. So actually the object itself is the boss object. As a thought, since only the boss should have those 5 employees, it could be an idea to create a separate boss object like this:
Note that this might also have drawbacks since Boss is now actually a different object than Employee, but it seems to fit the requirements.
Point f) seems to call for a generalization. So you would need a generalization towards SpecificJob. This would be an arrow with open triangle, not the one you used:
This actually reads Project and Activity are specific kinds of Job as they both inherit from the latter.
Let's say I have a collaboration diagram that models a process named CheckMessage which is quite complex and spans over few lanes and pools. Now I would like to model another process, e.g. CreateMessage which would make use of the previous process to check first if message doesn't exist already or if all its fields are valid, etc.
The thing is, that both processes make use of the same swimlanes and pools. What is the proper way to model such interactions? I was thinking to model CheckMessage as a sub-process of CreateMessage, however sub-processes can't be attached to pools or lanes - if I understand it correctly they just stay within a lane of activity which invoked them. Can a Call Activity encapsulate such beahviour (cross pools and lanes)? Or can I somehow reference the CheckMessage diagram as a whole?
Thanks in advance.
I could think of the following approaches:
Using Diagram Reference: This is used quite often when you want to switch easily to the more complex part. The disadvantage is that, unlike Fragments in SDs, you do not have ways to really connect flows in and out of referenced diagrams.
Repeating parts of the process: here you just pick those actions from the complex process which ought to interact with the other process. You can highlight that by putting a boundary around these and adding a diagram reference as described above.
Call Activity: This is another valid way. Here you have an activity which you instantiate as action. The advantage here is that you can add pins for input and output parameters.
I guess there is no silver bullet and you have to choose what is appropriate in each case.
Edit Regarding #3 it looks like that:
(this is an example and not to be used in practice)
The Action to the right is an instance of the Activity as you can see by Ctrl-L (show parent).
I have an entity in my domain that represent a city electrical network. Actually my model is an entity with a List that contains breakers, transformers, lines.
The network change every time a breaker is opened/closed, user can change connections etc...
In all examples of CQRS the EventStore is queried with Version and aggregateId.
Do you think I have to implement events only for the "network" aggregate or also for every "Connectable" item?
In this case when I have to replay all events to get the "actual" status (based on a date) I can have near 10000-20000 events to process.
An Event modify one property or I need an Event that modify an object (containing all properties of the object)?
Theres always an exception to the rule but I think you need to have an event for every command handled in your domain. You can get around the problem of processing so many events by making use of Snapshots.
http://thinkbeforecoding.com/post/2010/02/25/Event-Sourcing-and-CQRS-Snapshots
I assume you mean currently your "connectable items" are part of the "network" aggregate and you are asking if they should be their own aggregate? That really depends on the nature of your system and problem and is more of a DDD issue than simple a CQRS one. However if the nature of your changes is typically to operate on the items independently of one another then then should probably be aggregate roots themselves. Regardless in order to answer that question we would need to know much more about the system you are modeling.
As for the challenge of replaying thousands of events, you certainly do not have to replay all your events for each command. Sure snapshotting is an option, but even better is caching the aggregate root objects in memory after they are first loaded to ensure that you do not have to source from events with each command (unless the system crashes, in which case you can rely on snapshots for quicker recovery though you may not need them with caching since you only pay the penalty of loading once).
Now if you are distributing this system across multiple hosts or threads there are some other issues to consider but I think that discussion is best left for another question or the forums.
Finally you asked (I think) can an event modify more than one property of the state of an object? Yes if that is what makes sense based on what that event represents. The idea of an event is simply that it represents a state change in the aggregate, however these events should also represent concepts that make sense to the business.
I hope that helps.
I have actually two questions but they are kind of related so here they go as one...
How to ensure garbage collection of tree nodes that are not currently displayed using TreeViewer(SWT.VIRTUAL) and ILazeTreeContentProvider?
If a node has 5000 children, once they are displayed by the viewer they are never let go,
hence Out of Memory Error if your tree has great number of nodes and leafs and not big enough heap size.
Is there some kind of a best practice how to avoid memory leakages, caused by never closed view holding a treeviewer with great amounts of data (hundreds of thousands objects or even millions)?
Perhaps maybe there is some callback interface which allow greater flexibility with viewer/content provider elements?
Is it possible to combine deffered (DeferredTreeContentManager) AND lazy (ILazyTreeContentProvider) loading for a single TreeViewer(SWT.VIRTUAL)?
As much as I understand by looking at examples and APIs, it is only possible to use either one at a given time but not both in conjunction, e.g. ,
fetch ONLY the visible children for a given node AND fetch them in a separate thread using Job API. What bothers me is that Deferred approach
loads ALL children. Although in a different thread, you It still load all elements
even though only a minimal subset are displayed at once.
I can provide code examples to my questions if required...
I am currently struggling with those myself so If I manage to come up with something in the meantime I will gladly share it here.
Thanks!
Regards,
Svilen
I find the Eclipse framework sometimes schizophrenic. I suspect that the DeferredTreeContentManager as it relates to the ILazyTreeContentProvider is one of these cases.
In another example, at EclipseCon this past year they recommended that you use adapter factories (IAdapterFactory) to adapt your models to the binding context needed at the time. For example, if you want your model to show up in a tree, do it this way.
treeViewer = new TreeViewer(parent, SWT.BORDER);
IAdapterFactory adapterFactory = new AdapterFactory();
Platform.getAdapterManager().registerAdapters(adapterFactory, SomePojo.class);
treeViewer.setLabelProvider(new WorkbenchLabelProvider());
treeViewer.setContentProvider(new BaseWorkbenchContentProvider());
Register your adapter and the BaseWorkbenchContentProvider will find the adaption in the factory. Wonderful. Sounds like a plan.
"Oh by-the-way, when you have large datasets, please do it this way", they say:
TableViewertableViewer = new TableViewer(parent, SWT.VIRTUAL);
// skipping the noise
tableViewer.setItemCount(100000);
tableViewer.setContentProvider(new LazyContentProvider());
tableViewer.setLabelProvider(new TableLabelProvider());
tableViewer.setUseHashlookup(true);
tableViewer.setInput(null);
It turns out that first and second examples are not only incompatible, but they're mutually exclusive. These two approaches where probably implemented by different teams that didn't have a common plan or maybe the API is in the middle of a transition to a common framework. Nevertheless you're on your own.