I am implementing a game application using orleans framework. Every game instance is a separate GameGrain and there are some associated grains with every instance of GameGrain like PlayerGrain (for every player in the game), WeaponsGrain (weapons inventory).
The primary key of these grains are:
GameGrain : <GameGuid>
PlayerGrain : <GameGuid>-<PlayerGuid>
WeaponsGrain: <GameGuid>
Now, I want to implement grains placement strategy that makes sure that GameGrain, PlayerGrain and WeaponsGrain for any game instance is activated on same silo as the GameGrain
Would appreciate if you can provide some inputs as how I should do this?
You can mark a grain with the attribute [PreferLocalPlacement] if you want it to be placed on the same silo as the grain that created it.
Other placement strategies are available and you can even write your own. Read the documentation on grain placement for more information on this.
As there is a cost associated with grain communication and you are concerned enough about this to be thinking about grain placement, then you may want to rethink what objects should be grains. If an object does not need to be accessed by multiple grains and is truly owned by a grain, then you may just want to make it part of the same grain.
A weapon for instance could be an object in a collection of weapons in a player grain. If it needs to change ownership, the object could be sent to another player grain.
Related
How to refactor/rewrite an association into inheritance in the following example.
The UML Diagram describes the currently working state of my program. The real code structure is more complex so please excuse this made-up example.
There is a Market which initially holds some computers types in a list. When a computer is sold a new object SoldComputer is created and added to a second list. The sold computer references to the computer type. The CPU of the first computer sold can be called by:
soldComupter.ReferenceComputerType.CPU
Is it possible to replace the association with inheritance? Removing ReferenceComputerType and inherit SoldComputer from ComputerType. A call would look like this:
soldComupter.CPU
The goal is not to disguise the reference by a decorator pattern but to descant all field and functionality by inheritance.
The problem i struggle with is, that multiple sold computer can reference the same computer type. So i cant typecast an existing computerType into a soldComputer as both list must exist at the same time in the real application.
If I understand correctly your reasoning, your market sells SoldComputer which are categorized according to a generic ComputerType. Furthermore the ComputerType pre-defines some characteristics of all the computers of that type.
Composition over inheritance
First, a Computer is not a ComputerType. But looking at the properties of these classes, it appears that my argument is only about a naming issue, because your ComputerType could also be named GenericComputer, in which case it would be less shocking.
But your ComputerType is only a small part of the problem. Because sooner or later, you'll realise that a sold computer can also have some StorageType (e.g. HDD, 1To) and maybe also some GraphicType, and many other configurable options. And tomorrow, you may even have new type of components you are not even aware off (e.g. holographic beamer 2D/3D) but that fundamentally do not change the way you describe and categorize the SoldCompter.
This is why you should prefer composition over inheritance: you could have association with other types of components. The big advantage, of your current approach is that if a user decides to extend the RAM of its SoldComputer, he/she can choose just the matching ComputerType and everything is fine.
If you'd go for inheritance, the SoldComputer would have its CPU and its memory: if the user would change their value, it would be inconsistent with the categorisation. And maybe there is no copmuter type corresponding to the new categorisation...
Alternative
Another way to look at the problem is to have a class Computer with all the fields that technically describe the computer (e.g. CPU, memory, disk, etc...):
the set of computer types in the market would be populated with Computer but with only some relevant fields filled.
the set of sold computers in the market would be populated with Computer having some owner.
The creation of a new Computer to be sold could use the prototype design pattern. But as soon as it is done, there would be no relation anymore between the computer and the prototype.
In this case, the market would no longer be categorised by compter type. The search would always be dynamic (eventually initialised using a choice list of the prototypes.
Is it possible to replace the association with inheritance?
No, it's not possible.
As pointed out by #ThomasKilian, "a computer IS NOT a computer type", or put more generally, a product IS NOT a product type.
Your model seems reasonable.
It's very common in business apps to have both a class for product types and another one for individual products, such that these two classes are associated for representing the information which type a product has.
Why would you like to use an inheritance/subclass relationship instead?
I have been looking for an example of this and I'm unsure of how this is done here, since grains are isolated.
Example: Say I have a User grain, which can reference X Order grains and each order grain has a collection of OrderItem grains associated with them. What is the preferred method of accessing all of these items?
The only way I have thought of is having a collection of PK's for each of the Order grains inside the User grain, and OrderItems within the Order grain, then call them as you would any grain.
Sorry if this is a little novice of a question, but I haven't been able to find a good example solution to review.
Sounds like you are partitioning way too narrow. Is there an actual reason why each order item (and perhaps even the order) is its own grain type? If it's just a data holder without any non-trivial logic, nor is referenced externally, I would just keep that data inside the Order itself, as it doesn't seem like each item should have its own identity.
If we map concepts to DDD terminology, each aggregate typically correlates to a grain type, and you wouldn't typically make each order item behave as an aggregate root.
So you just reference an Order grain that happens to contain all of its order items inside it.
That's basically just a generalization without knowing much about your actual domain. It IS possible in a few domains to treat order items as their own aggregate root, but make sure that's what you want, because the complexity of having them in isolation is not trivial (ie: what happens if the Order grain dies but not the order items, etc).
I'm using Parse (www.parse.com) for the backend database for an iPhone app. I'm creating a fitness application and want advice as the best way to structure the classes and relationships.
A few needs for the database:
1)Sets(have attribute or weight and reps)
2)Exercise (a single instance of an Exercise which can contain multiple Sets)
3)Workout (which will be a single instance for a particular workout which will represent 1 single day. No single day can have 2 Workout objects. Can contain multiple Exercise objects.
Then I also need some classes for Routine which is independent from the ones above.
4) Routine can contain ExercseForRoutine objects (which will look the same as Exercise but will just be used for routines, will not be able to add sets to.
5) ExercseForRoutine will be added to Routine, but not related to the actual Exercise objects that will be used when the user enters workout data, this object is just used to create a Routine.
Any advice on tips and how to structure this using Parse would be appreciated
Don't get too hung up on your object model or your data store. If you haven't done so already, generate a list of core use cases and use those to drive your object model. But assume that you will iterate on it until you find a good fit with your domain. The one thing that sounds like it might be a bit fishy about your spec is writing the single day constraint into your Workout class. That doesn't sound like it's essential to the domain and probably will be awkward to code (e.g., what happens if I start my workout at 11:55pm?).
I'm trying to comprehend ontology basics.
Here's an example:
car (class)
2009 VW CC (sub-class or instance?)
My neighbor's 2009 VW CC (instance)
My issue is understanding what is "2009 VW CC" (as a car model). If you're making product model a sub-class in the ontology - all of a sudden your ontology becomes bloated with thousands of subclasses of a "car". That's redundant. At the same time we can't say "2009 VW CC" is an instance, at least it's not material instance of a class.
Does it make sense to distinguish between regular instances and material (distinct physical objects)?
At the other hand, if both are instances (of different nature so to say), then how can instance inherit properties / relations of a non-class?
I hate to say it depends, but it depends.
If you need to model every single car in the world, and have methods that you can call on them (like "change tyre", which is a process that is very different for each model) then yes, you are going to have a lot of bloated classes, because your real world situation is bloated too.
If you just want to have a database of pictures of archetypal cars, and you don't car whether it is a picture of your neighbour's instance or your sister's instance, then you can drop the bottom layer. "2009 VW CC" could well be an instance, even though you can visualise that it is also a class in another model.
Alternatively, maybe you don't need to make it a true subclass at all. A simple reference might be sufficient. For example, an insurance company knows about a large list of car models and years, but the developers don't write one subclass for each. Instead, they have a database of car models, where one row may represent 2009 VW CC. When you insure your car, they create an instance of "Insured Car" with a reference to the "2009 VW CC" instance.
This doesn't strictly follow the "Use inheritance for a 'is-a' relationship", but the operations on all the car types are identical - it is just the parameters (e.g. insurance price per annum) that change, and new car models are recorded in the database, not in the code.
An assumption here is that you can model the differences between the difference models as merely parameters to the same methods on car.
(Aside: When the iPhone started becoming available through phone company web sites, I noticed that it broke their class models - their web-sites seemed to handle dozens of brands and models of phone on one page - presumably using a simple database of phones and their features - and then needed a special page to handle the iPhone models, presumably because new special methods were required on their classes to support some aspects of the iPhone sale. Automated sales desks would say "Press 1 to buy a phone. Press 2 to buy an iPhone.")
You have it backwards.
2009 VW CC inherits from the class car. Thus 2009 VW CC needs to know about car, but car doesn't need to know about 2009 VW CC. Though we do occasionally use the term "subclass" in reality, car knows nothing about any of its subclasses.
What's more interesting is if you consider prototypal inheritance (like in javascript), where objects inherit directly from other objects (imagine if your 2009 VW CC inherited the aspects of your neighbor's 2009 VW CC). In reality how this is implemented is that new object have a secret pointer back to the object they inherited from. If you think about this secret pointer you can see how the originating object doesn't become bloated.
Now if you're suggesting that multiple inheritance and long family trees can lead to confusing structures, then I would agree with you.
I really agree with Oddthinking. Plus, if you need car models as classes, "all of a sudden your ontology becomes bloated with thousands of subclasses of a car" actually is not a problem. Why should it be? You just define classes instead of individuals, you might have an 'abstract' ontology, with base classes, and a 'concrete' ontology, with classes that represent the particular situation in real world. This is not OOP, defining thousand classes that are actually somewhat in between between instances and classes is no big deal, at least conceptually, nobody consider this 'bloated' or strange in any other way. Indeed, they do it all the time in my field (life science, where we typically don't care about the proteins P53 in our body, so P53 is a class, even though it's also used to model a record in a relational database).
Except, well, my experience is that tools like Virtuoso seem optimised for the situation of few classes and many instances. In fact, I've observed significant performance improvements when I turned million of classes in Virtuoso into instances. So, well, it's complicated...
I've been trying to wrap my mind around DDD and how it can relate to MVC, but I'm having trouble with regards to entity identification.
In particular, I'm trying to maintain strict separation between my presentation, domain, and data models. My hangup here is in how I preserve entity identification across these boundaries. To clarify, I'm using separate classes to represent the same entity in different contexts - for example, I have a 'ShipmentRequest' domain class, several 'ShipmentRequestView' presentation classes (depending on the properties required by a particular view), and a 'shipment_request' database table (my data model).
I feel like using an 'ID' property (like ShipmentRequestId) would be a violation of the separation I'm trying to achieve, since this ID property is a database concern, and not a domain concern; and I don't want to pass the same object between layers, as this would mean passing unneeded data into my presentation layer.
How do I preserve this separation, and yet track identity between these layers?
Without the Id field in your entity you cannot map it to a database row. Therefore this id field even though it has nothing to do with your entities must leak into your domain model.
I feel it is most often overkill to use a presentation model, especially if what your are trying to achieve is hide some properties.
I think separation of concerns is mostly driven by the bounded context. For example, your Person, PersonView and Person table all seem the relate to a transaction processing context. In such a context I would make not even have a PersonView and the person table would be abstracted away.
On the other hand if you are in a reporting context, a PersonView would be more useful.
I think that the context is much more important than any layering scheme.
As for the lack of a natural key in your person entity, it could mean that Person is not really an entity. For exemple, in any real life application, there is always a number associated with the person: an employee has a employee number, a client as an account number, etc. This business id is definitely part of the domain.
I think having an "ID" field on entities is a concession a lot (most?) people end up making, and I wouldn't feel guilty for doing so.
As you say, even when you're not dealing with the database, you still need some notion of identity. You can try to come up with some kind of "natural" identity for each entity (a field like name, or a combination of several fields), but this isn't always possible. Even when it is, having an ID field often acts as a handy shortform for saying "the entity whose name is X, and whose date of birth is Y, and whose SSN is Z".
In the end, while arguably less "pure", having an ID field will likely simplify things a great deal.
Shipment Request is definitely a better example!
How will the users find a shipment request?
Depending on the answer you might need an id that users might remember, for example 20091012-A.
Can a shipment request id ever change?
If no, use the db key for identity.
Will you need to transfer shipment requests from one system to another?
If yes, do not use the db key for identity.
Whatever key you use you will need to make it available in the presentation model so that you can build links to actions on a particular shipment request.