A Peep inside a C# Application Service

http://themvcblog.typepad.com/programming/2012/10/a-peep-inside-a-c-application-service.html

by darindlaw • 14 years ago

26 25 14 years ago

themvcblog.typepad.com

pragmatic• 14 years ago

Ummm, what exactly is a "C# Application Service"?

This post has no introduction and dives right into the details.

cpher• 14 years ago

Glad I'm not the only one who wondered. I was beginning to think I missed the "latest thing."

hhudolet4• 14 years ago

App service is like API, facade, to which a presentation layer (web, mobile app) is connecting. Architecturally speaking, it doesn't have to be separate an app that connects.

skrebbel• 14 years ago

> When an Application Service receives control, it loads an Aggregate and retrieves any supporting Domain Services needed by the Aggregate’s business operation. When the Application Service delegates to the Aggregate business operation, the Aggregate’s method produces Events as the outcome.

I'm genuinely curious: does anyone here understand anything about that? What do those words even mean? I mean, even if you assume that the capitalized words are what's being explained, what's a "business operation"?

It's writing like this that give C# and .NET their (mostly undeserved) image of overarchitected concept jungles.

emp_• 14 years ago

Its part of DDD (Domain Driven Design) universe, an attempt to have standard patterns for large enterprisy software.

facorreia• 14 years ago

That's correct, those terms come from Domain Driven Design terminology and are not related to C#.

You can learn more about it from this book:

Domain-Driven Design: Tackling Complexity in the Heart of Software

http://www.amazon.com/Domain-Driven-Design-Tackling-Complexi...

Locke16892• 14 years ago

This has nothing to do with C# and .NET. I think it's some kind of ASP.NET framework. As far as I know, C# and .NET do not have this reputation (at least, no more than other technologies in the same space, like Java).

hhudolet4• 14 years ago

It has nothing to do with any lang or framework, blog author could put Cobol example probably, its more like app architecture.

shaydoc3• 14 years ago

C# is a great programming language. I think this looks a bit like a service bus to me!

Locke16892• 14 years ago

This seems to be some kind of ASP.NET thing. It has nothing to do with the C# language, as far as I can tell.

hhudolet4• 14 years ago

Nope, its not related to any presentation technology or framework.

codehobbit• 14 years ago

it's domain driven design, quite some new concepts ey ?

tarr11• 14 years ago

So, I generally like Dependency Injection (except that it makes things hard to debug) The code tends to be cleaner and there's less of it. It's also easier to test.

But I really dislike reading this kind of code. It is just really hard to understand. And if it's hard to understand, it's hard to maintain.

untog3• 14 years ago

It's stuff like this that gives C# a bad name. If you strip away the enterprise-y, ASP.NET stuff it's usually wrapped in, it's a fantastic language.

After having spent a lot of time working in Javascript (and node.js specifically), I'm diving back into C# in my spare time, but learning to forget all the nonsense- no factories, no web.config, no ASP.NET framework... it's great. One highlight is Nancy.fx[1], a very lightweight web framework. Setting up routes is as simple as:

    Get["/list"] = parameters => {
        return "The list of products";
    };

I'm also developing on a Mac with MonoDevelop- it's a poor cousin of Visual Studio, but it works just fine. I feel like there is a series of "C# without the crap" blog posts to be written- I hope to do so.

[1] http://nancyfx.org/

shaydoc3• 14 years ago

Asp.net webapi is quite good, I have to say!

untog3• 14 years ago

I haven't had a chance to look at it, but have heard good things.

The sad thing is that even ASP.NET MVC- which is 100x better than WebForms- is used 0.001 as much. The same fate may apply to the Web API. It just doesn't seem like there is much interest.

smhinsey• 14 years ago

I agree with you about Nancy, and I also use ServiceStack alongside it, but I don't think the linked article has anything to do with ASP.NET specifically. The author does seem to be an ASP.NET MVC guy though.

hhudolet4• 14 years ago

Think its related to this: http://prezi.com/v9lvosve93i3/changing-the-mindset-more-obje... Event sourcing (eventstore) is different way of modelling complex business logic in object oriented language. Where you think about behaviour and verbs of your business, not data, properties, tables and relations. Not for CRUD apps, web portals, simple web shops, CMSs and similar apps.

darrenkopp• 14 years ago

It seems like this article could use explanation as it seems that many of the comments here either are incorrect or are asking for explanation. I am not the author, but I do have a fairly good understanding of what is going on here.

First off, this has nothing to do with asp.net, wcf, etc. This is really JUST about event sourcing, with a tiny bit of "application service" at the start. The application service bit is actually what you would call from asp.net, wcf, nservicebus, some message queue handler, etc.

So I think first we should define a couple of terms used in this that are "Domain Driven Design" terms that I'll flesh out a bit.

* Application Service - This is a significant process whose responsibility does not fit well onto an object. Simplistically, think about this as a cohesive business process that orchestrates various objects.

* Aggregate Root - This is an entity (something with identity, such as a key) that is the logical root of an object graph (though the graph may only be the object itself, as is the case with customer).

Most of what you are seeing in this article is known as "Event Sourcing", which is to say that the current state of an object is built up by the history of events (changes) to the object. Since this is DDD, don't think of changes as in "field a changed value from b to c", but more of logical "business relevant" events like "customer address changed".

So what's happening in this article is this:

The `CustomerApplicationService.LockForAccountOverdraft` method requests the full history of events for the customer and creates the customer instance using those events. We now have a valid customer instance.

Next, we call the `Lock` method on customer, and give it the reason supplied to the `LockCustomer` method. Here, we create a new instance of CustomerLocked, which is an event signalling that a customer was locked. This event instance is pushed into the `Changes` collection and then executed against the customer instance, which sets the `ConsumptionLocked` property to true.

So in event sourcing the objects state is derived by it's previous events, so the `When(CustomerLocked e)` method is called when the matching event is passed to the mutate method. This happens in 2 places: when initializing from previous events, and when we are pushing the new event. The CustomerLocked event is pushed to the Changes collection because the event store will append that event to the stream on commit (transaction completion).

Now, someone stated that this looks like service bus, which is correct, but slightly different. Once the changes have been committed, the event store then publishes those events, typically onto something like a service bus, message queue, etc, and that event can then be consumed by other processes interested in that event.

So, where does this get us? Is this some over-architected ivory tower software? Well, the answer depends on what is important to you. In some scenarios, this is; in other scenarios this is ideal. The answer is basically defined by what matters to the business, which will define if keeping track of the state transitions is useful to you or not.

So, what are the benefits of event sourcing? Basically, the core benefits are the following 2 things:

1. Guaranteed correct state. Since our state is built up by what has happened, which cannot change since it happened, we are guaranteed to be in the correct state. This also protects state from external changes, like integration through a the database that could put things into an invalid state, etc.

2. By virtue of building up ourselves from our events, other things (external processes, etc) can also consume those events in various ways. This is where CQRS comes into play, or rather, why CQRS usually involves an event store for the writeable side.

So, that's a high-level overview of what's happening in the article and on event sourcing, but very simplistic overview, glossing over a lot of other core concepts.

rcknight• 14 years ago

I was hoping someone would come in and spend the time to explain this, the comments were getting pretty depressing!

Event sourcing CQRS are very interesting once you get your head around the use cases.

sakopov• 14 years ago

This looks like CQRS. Very useful pattern where you need to playback transactions or events for any completed unit of work.

A Peep inside a C# Application Service

Related Stories