Me again.. I hear the phrase 'decorating / decorate' a method being thrown about a lot in tutorials I have read / watched. But I just don't understand what it means AND what it actually does?? Can anyone point me in the direction of some information on beginning to use them (Very novice tutorial would be good)
.NET does not have "decorators" but it does have attributes. Developers often use the word "decorate" to indicate the usage of attributes. Here is a good article explaining how they work and how to use them.
Take a look at this article for an introduction and tutorial.
To Decorate in .NET you use attributes which act as metadata that is available to you at runtime which helps describe the items in your code.
If your talking about the Decorator design pattern there is a very clear example on dofactory.com.
Hope this helps
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
I've been programming in Delphi with Midas/DataSnap for quite long time and quite happy with it. Moving to .NET I'm more than happy with the ADO.NET DataSet. For CRUD application, I'm highly uncomfortable with any kind of ORM. Generic data-structure with automatic diff/delta handling get my job done better for me, an average database application developer.
Tried to study Java years ago, and could not find similar idea implemented. The closest I could find is SDO (Service Data Object). I thought it should be widely adopted when I saw it, but I'm wrong. Even the spec is rather old now, I still hardly find many people discuss on it or use it extensively. Assuming from information I can find on the internet, SDO usage is highly passive.
Wondering if it's dying ? Any experience in SDO you want to share ? Manual DTO coding is always better ?
Ok. I see. The answer is "no"
;)
Same for me when trying SDO first time. Old specs, passive feedback... Definitely NO.
I wouldn't recommend using SDO unless it's imposed on you by some other part of the project.
WebSphere process server uses SDO. It's not really a bad API once you learn it. But the spec and the documentation are vague. It doesn't spell out what happens if you ask for a field that doesn't exist, or whether it does type conversions while getting or setting fields, to name two gripes.
I don't think the API defines how to define new types, so that part will be implementation-specific. Type definitions are based on XSD, so you'll be working with those and all of the associated standards.
As others have implied, the API isn't widely used. This means it'll be hard to find people experienced with it, or help using it.
Sorry about the vocabulary question, but I'm writing my master thesis and it's a pain to repeat "frameworks that support dynamic class creation" again and again. Is there a term for that?
Some clarification: I mean that you can create a class at runtime, i.e., dynamically. For example, .NET supports this with the System.Reflection namespace.
Thanks :)
Haha, thanks everyone for the suggestions. I'm not going to pick an answer yet in case there is a term for this and someone finds it, but if there isn't I'll definitely make one up. Thanks. :)
DCC Framework, Invent an acronym.
Dynamic class creation is covered by the term "metaprogramming", although metaprogramming includes more than that.
It's more the development language rather than framework
A reflective programing language enables the determination of object type at runtime. Most (if not all) include some sort of class loading mechanism to dynamically create objects at runtime as a result.
You could try...
Reflective Framework?
Introspective Frameworks?
When I first heard about ASP.NET MVC, I was thinking that would mean applications with three parts: model, view, and controller.
Then I read NerdDinner and learned the ways of repositories and view-models. Next, I read this tutorial and soon became sold on the virtues of a service layer. Finally, I read the Fluent Validation documentation, and I'll be darned if I didn't end up writing a bunch of validators.
Tonight, I took a step back and thought about what had become of my project. It seems to have become the victim of the design pattern equivalent of "feature creep". Somehow I'd gone from Model-View-Controller to Model-Repository-Service-Validator-View-ViewModel-Controller. You want loosely coupled and DRY? We got your loosely coupled and DRY right here! But I'm wondering if this could be a case of too much of a good thing.
Am I right to be concerned? Or is this actually not as crazy as it sounds? On one hand, it seems crazy to have so many layers. On the other hand, every layer has a clearly defined purpose that makes sense to me. Have your MVC applications turned into MRSVVVMC apps too? If not, what do they look like? Where's that right balance?
If you have one form with three attributes, this is overkill.
But if you have a 'real' application, and the responsibilities of each layer are well defined, I'd consider it pretty reasonable.
It sounds to me like you found a pattern and went looking for a problem. You should find a problem, and use the appropriate tool from your toolbox... not all the tools. Unless this is an academic exercise of course.
For various common reasons I wanted to use tracing for my ASP.NET application. Especially since I found out about the possibility to use the Service Trace Viewer tool which allows you to examine your traces in a powerful way.
Since I had never used this trace thing before, I started stuying it. After a while of Google, SO and MSDN I finally have a good idea of how things work. But I also found one very distrubing thing.
When using trace in ASP.NET applications it makes a lot of sense to group the trace messages together by web requests. Especially since one of the reasons I want to use it is for studying performance problems. The above mentioned tool also supports this by using <Corrleation> tags in the generated XML files. Which in turn come from System.Diagnostics.Trace.CorrelationManager. It also allows other nice features like Activity starting/stopping, which provides an even better grouping of trace messages. Cool, right?
I though so too, until I started inspecting where the CorrelationManager actually lived. After all - it was a static property. After some playing around with Reflector I found out something horrifying - it's stored in CallContext! Which is the kind of thing we shouldn't be using in ASP.NET, right?
So... am I missing something here? Is tracing really fundamentally flawed in ASP.NET?
Added: Emm, I'm kinda on the verge of rewriting this stuff myself. I still want to use the neat tool for exploring the traces. Any reason I shouldn't do this? Perhaps there is something better yet? It would be really nice if I got some answers soon. :)
Added 2: A colleague of mine confirmed that this is not just a theoretical issue. He has observed this in the system he's working on. So it's settled. I'm going to build a new little system that does things just the way I want it to. :)
Added 3: Wow, cool... the guys at Microsoft couldn't find anything wrong with using Correlation Manager in ASP.NET. So apparently we're not getting a fix for this bug after all...
You raise a very interesting question. After looking at Reflector, I also see that CorrelationManager is using the CallContext to store the activity id. I have not worked with tracing much, so I can't really speak on behalf of what types of activities it tracks, but if it tracks a single activity across the entire life cycle of a page request, per the article you referenced above, there is a possibility that the activity id could become disassociated with the actual activity. This activity would appear to die halfway through.
HttpContext would seem ideal for tracking an entire page request from beginning to finish, since it will be carried over even if the execution changes to a different thread. However, the HttpContext will not be transferred to your business objects, where as the CallContext would. On a side note, I saw that CallContext can also be transferred when using remoting between client and server apps which is pretty nifty, but in the case of tracking the website, this would not really be all that useful.
If you haven't already, check out this guy's site. The issue described in this article isn't specifically the same issue that Cup(Of T) article mentioned, but it's still pretty interesting. He also provides several very informative links on the page that describe components of the CorrelateionManager.
Unfortunately, I don't really have an answer to your question, but I definitely find the topic interesting and will continue looking into it. So please update this post as you learn more. I'm curious to see what you or others (hopefully someone out there can shed some light on the topic) find while looking into this.
Anyway, good luck. I'll talk to some of the peeps at my work about this and post more later if I find anything.
Chris
OK, so this is how it ended.
My colleague called Microsoft and reported this bug to them. Being certified partners means we get access to some more prioritized fixing queue or something... don't know that stuff. Anyway, they're working on it. Hopefully we'll see a patch soon. :)
In the mean time I've created my own little tracing class. It doesn't support all the bells and whistles that the default trace framework does, but it's just what I need. :) More specifically:
It writes to the same XML format as the default XmlWriterTraceListener so I can use the tool to analyze the logs.
It has a built in log rotation - something my colleague had to do himself on top of XmlWriterTraceListener.
The actual logging is deferred to another thread so performance can be measured more accurately.
Correlations are now stored in HttpContext.Items so ASP.NET threading peculiarities don't affect it.
Happy end, I hope. :)