In the screecast presentation Jonathan Oliver gave regarding his EventStore implementation He mentioned the ability to query the events, for example to make a complex temporal query. From what I understand this is done through updating a read model or creating projections after the eventstore is updated - however I can't seem to see any examples of this using the J.O's implementation. Any links to or examples would be great!
The querying mechanism of EventStore v3.x is a little...sub par at this stage. But technically speaking, that was never the intended purpose of the EventStore in the first place. Instead, it was to persist the events and make them available for future use. That being said, you're welcome to use whatever querying mechanism you feel is necessary to pull the events out of the underlying data store and to run them through your code to "project" the events into a particular view or read model.
Article that describes temporal query is e.g. http://codeofrob.com/entries/evented-github-adventure---temporal-queries,-who-doesnt-trust-their-hardware.html
It is based on projections and you can see a nice example there.
Related
I was referring to the Axon documentation trying to implement a Saga: https://docs.axoniq.io/reference-guide/axon-framework/sagas/implementation
As is the case with everything else I've encountered thus far in Axon's documentation I could see no big picture, no diagrams or code examples or even any reference to example code in Github to help me get started.
I know what Saga means conceptually and what it solves. What I'm unable to understand from the documentation is how to apply that concept using Axon's artifacts. There is not one area that is written holistically and completely.
Does anyone have any good reference, books that helps me apply Axon? I'm currently evaluating Axon (and I'm not willing to buy the "support") and the quality of the documentation has almost forced me to look elsewhere (Eventuate).
I wrote this blog about Saga's with code samples I hope this helps you to get started.
Next to the blog that Yvonne has shared, you could take a look at this book from Vijay Nair:
https://www.amazon.com/Practical-Domain-Driven-Design-Enterprise-Java/dp/1484245423
It explains several approaches towards building DDD applications, with the last one diving into Axon's idea of it.
Added, AxonIQ is working on a training environment:
https://academy.axoniq.io/
So, a website with videos and written material about anything Axon-related.
The two courses that are on there right now, are free. Granted, Saga's/Process Manager aren't present there yet, although they should come soon.
When it comes to sample applications using Axon (that are maintained by AxonIQ developers), I'd refer to these:
https://github.com/AxonIQ/hotel-demo -> complete application touching as much of Axon's components as possible
https://github.com/AxonIQ/code-samples -> repository containing more fine-grained samples
https://github.com/fraktalio -> contains several sample projects, of which I'd recommend the restaurant, order, and courier demos
Apart from sharing the info, I am sad to hear you find the Reference Guide lacking at this stage. Any recommendations on improvements are from your current description, rather vague to be honest. If you have the time and interest to enhance this open source product, know you can always open some issue for the guide too. I am not asking you to write the documentation, but a description of the missed would be much appreciated.
https://github.com/AxonIQ/reference-guide
Hi I am building a small app to get used to Meteor (and Mongo). Something that is bothering me is the data modelling aspect. Specifically what is the best way to model a many to many relationship. I have read in the Mongo docs that a doc should not be embedded in another doc if you expect it to grow while the original doc remains fairly static.
In my test app students can register for courses. So from the Mongo perspective it makes sense to include the students as an embedded doc in the course as each course will have a limited number of students as opposed to the other way round where, over time, a student could theoretically join unlimited courses.
Then there is the Meteor aspect, I read that a lot of Meteor's features are aimed at separate collections, such as DDP working at the document level so any change in the student array would cause the entire course doc to be resent to every browser, and things like the each spacebars helper works with Mongo cursors but not with arrays etc, etc.
Has anyone dealt with a similar situation and could they explain what approach they took and any drawbacks they had to deal with etc? Thanks.
See this article: https://www.discovermeteor.com/blog/reactive-joins-in-meteor/
And test how good your possible solutions are with this https://kadira.io/
Better use the guide:
http://guide.meteor.com/data-loading.html#publishing-relations
The Meteor team tames (or hides!) the javascript monster to an amazing extent. By using their conventions, you get "free" a ton of much-used functionality "out of the box". Things that are usually re-invented over and over again, accounts, OAuth, live data across clients, standard live-data protocol etc.
But very soon... you need features not in the box. Wow... look at all the choices. Wait a minute, this is the same monster you were fighting before Meteor!
So use the official Meteor Guide. They recommend the wisest ways to extend functionality of your app when you make these choices.
Since they know how they have "hidden the monster", they know how to keep avoiding the monster when you extend.
I started Meteor a few months ago.
I would like to know if using cursor.observeChanges for buisness objects is a good idea
I want to separate operations and views so I can uses the same operations in many views/events, and I want to know if it is a good idea.
Someone told me, we should not separate operations on mongo from view.
So my question is : Is it a good idea to to Buisness Objects with Meteor ?
Tanks for reading me.
cursor.observeChanges is essentially what you get behind the scenes when you do normal find() queries and bind to template helpers due to its context being reactive.
In the meteor world, the traditional model/view/controller paradigm is shifted towards a reactive data-on-the-wire concept including features like latency compensation.
What you refer to as a business object is basically a representation of your business data which is strongly typed, has a type of its own, atomic, and has only one task of representing.
You can achieve that kind of separation of concerns in any language/framework, including meteor. That only depends on how you lay out, structure and abstract your code.
What Meteor brings into the equation is the toolset to build up an interface to your data with modern ux features that are otherwise very hard/expensive to get.
The only concern over business-class applications could be the fact that Meteor currently employs MongoDB by default. MongoDB has its own discussions around business applications whether they need transaction support, ad-hoc aggregation, foreign key relationships etc. But that is another topic.
I'm getting ready to do a small, brief architecture spike using the EF code-first approach, introduced by Scott Gu here and here. Before I do, I'd like to know whether it will be worth it. Currently I have a project that uses the EF POCO Generation template, and I'd like to investigate the advantages I can get out of switching to a more pure POCO strategy for the domain model. Particularly, these are the things I'm interested in:
Avoiding automatically-generated partial classes with collection fixup methods, and being able to concentrate on essential domain object code without worrying about association persistence.
Avoiding having to transform templates every time I want to add an artifact to the model.
Still being able to have some control over the strategy of table persistence (locations of ComplextTypes, table-per-type versus table-per-hierarchy, etc). These aren't as important as the other 2 concerns.
The most recent version I could find of this was the CTP4, released summer 2010. Is this the most current version?
What are the cons of choosing this approach, using this particular library? Can you recommend any other concerns I should investigate in the spike?
Go through these tutorials and check this blog about some additional topics like inheritance - it will give you pretty good overview of Code First in CTP5 which should be close to final version as stated here:
CTP5 will be our final preview of Code
First and the simplified API surface
(DbContext) before we offer a full
supported production ready release in
Q1 of 2011.
I think all three points you mentioned are satisfied by current version.
Getting data from a database table to an object in code has always seemed like mundane code. There are two ways I have found to do it:
have a code generator that reads a database table and creates the
class and controller to map the datafields to the class fields or
use reflection to take the database field and find it on the class.
The problems noted with the above 2 methods are as noted below
Method 1 seems to me like I'm missing something because I have to create a controller for every table.
Method 2 seems to be too labor intensive once you get into heavy data
access code.
Is there a third route that I should try to get data from a database onto my objects?
You normally use OR (Object-Relational) mappers in such situations. A good framework providing OR functionality is Hibernate. Does this answer your question?
I think the answer to this depends on the available technologies for the language you are going to use.
I for one am very successful with the use of an ORM (NHibernate) so naturally I may recommend option one.
There are other options that you may wish to take though:
If you are using .NET, you may opt to use attributes for your class properties to serve either as a mapping within a class, or as data that can be reflected
If you are using .NET, Fluent NHibernate will make it quite easy to make type-safe mappings within your code.
You can use generics so that you will not need to make a controller for every table, although I admit that it will be likely that you will do the latter anyway. However the generics can contain most of the general CRUD methods that is common to all tables, and you will only need to code specific quirks.
I use reflection to map data back and forth and it works well even under heavy data access. The "third route" is to do everything by hand, which may be faster to run but really slow to write.
I agree with lewap, an ORM (object-relational mapper) really helps in these situations. You may also want to consider the Active Record pattern (discussed in Fowler's Patterns of Enterprise Architecture book). It can really speed up creation of the DAL in simple apps.