How will you make it if you never even try?

October 13, 2010

Hello, JavascriptMVC!

Filed under: ASP.NET MVC, Javascript, JavascriptMVC, JQuery, SproutCore — charlieflowers @ 11:37 pm

I am *very* excited about the fact that the project I’m working on has just decided to use a powerful framework called JavascriptMVC.

JavascriptMVC is a framework that helps you build and maintain robust Javascript client-side applications. It gives you Models, Views and Controllers inside of Javascript. It gives you dependency management between Javascript files. It gives you unit tests that you can run in the browser, OR from a command line in a browser-simulating Javascript environment as part of your Continuous Integration build. It gives you a lot of fantastic tools for going further with your Javascript than just adding some bling to your server-driven web pages.

I mentioned in my last post that I believe SproutCore is far and away the best framework for building interactive web apps in Javascript. That’s true. However, JavascriptMVC is also an excellent choice, and I’m very much looking forward to working with it.


SproutCore Rocks, and you will be hearing about it

Filed under: ASP.NET MVC, Javascript, JQuery, SproutCore — charlieflowers @ 11:24 pm

SproutCore is an AWESOME framework for building rich internet applications in JavaScript. In a nutshell, it’s like having Cocoa inside of JavaScript (but better) … and the world is just starting to realize that is the “Right” way to be building web apps.

I have to admit, though, it sounded crazy and weird to me 2 weeks ago. But that was before I and others on my team started to be able to articulate and understand some of the problems we were running into and some opportunities for fixing them (as I described in my last post).

Look, Javascript is now a solid, reliable, powerful language for serious development. “I know,” you reply, “and that’s why I’m using JQuery and Ajax.” Right, that’s “level 1” awareness that Javascript is now a real, reliable language. At that level, your MO is to build the same server-driven web apps we’ve been building (in Rails, ASP.NET, or whatever), but to sprinkle in some JavaScript for some “bling”.

But after you do that for a while, you may find yourself staring at “level 2” awareness that Javascript is a real, reliable language. That’s when you say, “Hey, why don’t we build a full-blown dynamic GUI in JavaScript, that is in control of its own “flow”, that *can* choose to pull some data from a server, or send some data to a server, if and when it wants to. After all, JavaScript is a *real* language suitable for real development.”

This has been dubbed the “thin server architecture”. Your server sends and receives JSON, and does not *at all* involve itself with html or any presentation concerns. And your client doesn’t even have to follow a “page” model (although you’re likely to be running in a browser and want the back button to feel normal, so you might “map onto” a page model). Your client can be rich, and can pull great ideas from GUI toolkits such as Swing, AWT, Cocoa, etc.

And I really believe the best framework out there for doing this is SproutCore. It severely lacks documentation, but that doesn’t matter as much as you might think, because the source code for it is absolutely beautiful. It is elegant, succinct, and well-factored. That plus some of the excellent tutorials out there really put a tool of enormous power in your hands. Once you make an initial investment in deeply understanding SproutCore, I really believe you gain the kind of power that lets one person do the amount of work that previously required 10 people.

Check it out. Unfortunately, my current project just decided not to use it. It was just too weird to them. There were a lot of developers on the team who balked at learning something so “different”. What they couldn’t see was that the tool is so powerful that only 1 or 2 people would need to learn it, and our UI would simply become a “solved problem.” Oh well, I can understand … the world hasn’t yet caught up to the “level 2” awareness that I mentioned above, and so SproutCore seems weird.

But you wait 6-12 months, and I bet you everybody and their brother will have heard of SproutCore, and more than just the “cool kids” will be using it. It is going to leave its mark on the web development world.

October 6, 2010

Going Beyond ASP.NET MVC and JQuery

Filed under: ASP.NET MVC, C#, Javascript, JQuery, SproutCore — charlieflowers @ 11:14 pm

I’ve been having a blast for the past year building an app in ASP.NET MVC (I’ll call it “MVC” through the rest of this post) and JQuery. And I’m very fond of both.

But an interesting thing happens when you build something complex with these 2 technologies. You’re very likely to find yourself facing a conundrum regarding how far to go with Javascript.

Here’s how it happened for us…. We started out trying to keep our logic on the server as much as possible. We can utilize the full power of C# and the .NET framework there. Even our controllers are unit testable, thanks to MVC and IoC. We have mature tools and patterns for unit testing that code. We can refactor it with Resharper. Etc, etc.

But of course, the beauty of JQuery and MVC in tandem is that you can make your web apps more interactive and responsive. So of course, we did some JavaScript on the client. Matter of fact, we didn’t shy away from any UI request our business users had. “You want a grid that lists Personal References, and the ability to select one from the list and Edit it? You want to be able to add new and delete from the list? Cool, we can do that without a single postback.”

And we have done that. And it is nice. A responsive web app with some nice usability features. But here’s where the conundrum comes in.

To make it nicer, snappier, more responsive and even more usable, we’d like to add more JavaScript. And we’d like to use Javascript in more places than we do currently. Sometimes, we wonder why we’re even building HTML on the server … why not return JSON from the server, and have some Javascript code on the client generate a DOM from it? That would certainly make better usage of bandwidth.

But … the JavaScript we have is already complicated. And when you’re building a UI with Javascript, you don’t have a lot of the benefits that you’re accustomed to in other UI technologies, such as change notifications, widgets, controllers, mature unit testing capabilities that are built in to your build process, etc. So the grid for Personal References, for example, took a while to get right. We were working at a primitive level, with individual DOM elements, click events, grid rows, etc.

The key realization was this: You either need to keep the amount and complexity of your Javascript very, very limited, or you need to really jump all in and do almost all of your UI work in Javascript. Anything in-between is a no-man’s land.

If you keep the Javascript very limited (more limited than what we needed for that Personal References screen, for example), then MVC and JQuery are enough for you to keep matters well in hand. But when you approach moderate or greater complexity, you need to make a quantum jump to a very Javascript-centric approach. And when you do that, you need Javascript Framework capabilities, for things like change notifications, controllers, widgets, unit testing, etc.

At that point, you have grown beyond just ASP.NET MVC and JQuery. Of course, both of those may still play a role in your solution, but you need more. It’s at this point that you should consider things like SproutCore, Cappuccino, JavascriptMVC, etc.

Which are some of the things we’re thinking about now.

February 27, 2010

The CQRS Light Bulb Moment

Filed under: ASP.NET MVC, C#, CQRS, Domain Driven Design (DDD), nhibernate, nServiceBus, OLAP — charlieflowers @ 11:17 pm

As I recently blogged, the project I’m on has recently decided to move to CQRS (Command Query Responsibility Segregation). We’re going to use nServiceBus as a message bus that let’s us separate our system into 2 “channels”: The “Read side” and the “Write side” (aka, the “Query side” and the “Command Side”).

This decision has been the result of several “Light Bulb Moments”, in which various ones of us had a flash of insight that helped us see how an architecture that at first sounded wierd and unorthodox would actually solve a number of problems and help us tremendously.

I’ve decided to share here one of those Light Bulb Moments in raw form. Here’s the text of an email I sent to two other architects on our team (over the weekend, from my own account … we talk about this stuff all the time because we love it). It expresses well many of the reasons we made the move (although I understand more about CQRS at this point and would tweak a few details). (Note: Names changed to protect the guilty).

The Email…


I’m seeing the opportunity to do something truly awesome here. It is based on the CQS reading I’ve been doing while thinking about what our “dto’s” or “commands” or etc. should look like.

I have created, worked with, and seen first hand the power of an OLAP database for read operations. It really is unbelievable in terms of the freedom it gives someone looking at the data. And it lets reads be very fast. But a lot of projects I’ve been on have said, “Let’s build the transactional system first. It is so obviously core to our business that we need it, and we need it yesterday. Once we get that done, we can think about maybe doing OLAP.”

But the way people are approaching CQS as a architectural concept these days, we have the opportunity to do both at the same time. It should help us get to the finish line faster, with screaming fast software and high scalability.

And it’s not that big of a change from what we’re doing now. It boils down to this:

1. We make the “flat view models” you guys are working on. They are designed to serve the view that they populate, and nothing else.

2. We express our edits to the domain in terms of “Commands”. These are merely Declarative … you look at one and it intuitively makes sense.

3. Our Domain Objects accept those Commands and process them. Our Domain Objects apply rules to decide whether or not a Command is valid. The Domain Objects have complete authority over accepting or rejecting an Edit Command.

4. Once the Edit Command is accepted by the Domain Objects, it is “applied”.

Now, right now, you’re both saying, “No shit, that’s what I said on Friday.” Yes, but let’s take stock of where this puts us, and see what else it allows us to do.

5. Since those “flat view models” don’t enforce any important business rules, they don’t have to come from our Domain Objects. (They can STILL come from NHibernate if that’s important or helpful, but they don’t have to come from our Domain Objects). Remember, our Domain Objects are in charge of *writing* all updates. Therefore, the written data can include calculated fields and anything else necessary to ensure that what comes back in on the read side is valid and complete. Complete domain integrity is maintained by the Domain Objects, so Reading is simplified. Needing a bunch of business logic on read has some challenges to it, plus I don’t think we have very many (maybe not any) kinds of calculated fields that would really require a full domain object.

6. We *are* still talking about NHibernate pulling the data that ultimately goes into our View Models. So there are probably some “DTO’s” that are *also* mapped to the same NHibernate tables that our Domain Objects write to. But those DTO’s can be “screen-shaped” (more accurately, “task-shaped”, since we want to include web services and other users of our system besides just the web-based human interface).

7. Now, the domain no longer needs many (possibly any) getters or setters.

8. Every single Edit Command can cause 2 things to happen: 1) our normalized OLTP database can get updated by our Domain Objects with the new data. 2) The very same Edit Command can get queued somewhere else to cause an update to our OLAP database for read access. We can essentially get an OLAP database that doesn’t need ETL … it gets updated from our Edit Commands and only lags a few seconds behind our OLTP database.

9. The Edit Commands also make it easy for us to have *MANY* copies of the readable OLAP database. We can update 3 databases as easily as one. Now we can load balance between them, and they’re equivalent.

10. We don’t actually need the fix Billy added to submit disabled controls. After all, we *know* those values didn’t change. Why should we need them on a Post? Our Edit Commands can be as sparse as what the user actually changed. (This is a minor thing, but still worth mentioning).

11. Here’s one of the main benefits of the whole thing: Once we get to this point, when we make a new screen, we make a DTO for it and a View Model for it. *Both* are custom designed to fit the screen itself. They will be coupled to the purposes of that screen because they need to be … this is good coupling. However, that screen will not exert *any pressure whatsoever* on our Domain Model. Our Domain Model will simply be exactly what it needs to be to express the logic of the domain. Think about how much easier things will be for us than they are right now. Now, we have to have a Domain Object Graph, and a parallel DTO object graph, and (soon) a View Model that gets mapped from the DTO object graph. Keeping the parallel Domain Object and DTO in sync has proven to be something we invest a lot of time in. They were drifting apart before I added the ApplyEdits() stuff. I then added the Interfaces that sometimes have 4 or 5 generic types riding along. Sam went further with it and has cases with 8 or 12 generic types, including multiple levels of nesting. We’re working too hard here. *IF you LOVE THE SMELL OF DELETED BITS IN THE MORNING”*, then you are going to get enjoyment out of moving to an approach like this.

Normally, doing something to fix problems you are having requires some extra work you hadn’t anticipated, and is a bit of a setback, though necessary. In this case, the fix for some of the problems we’re running into actually opens up whole new vistas of possibility, and these opportunities basically come for free after applying the correct fix.

Blog at