Put the knife down and take a green herb, dude.
One feller's views on the state of everyday computer science & its application (and now, OTHER STUFF) who isn't rich enough to shell out for www.myfreakinfirst-andlast-name.com
Using 89% of the same design the blog had in 2001.
FOR ENTERTAINMENT PURPOSES ONLY!!!
Back-up your data and, when you bike, always wear white.
MarkUpDown is the best Markdown editor for professionals on Windows 10.
It includes two-pane live preview, in-app uploads to imgur for image hosting, and MultiMarkdown table support.
Features you won't find anywhere else include...
You've wasted more than $15 of your time looking for a great Markdown editor.
Stop looking. MarkUpDown is the app you're looking for.
|Monday, March 30, 2015|
I've been considering using AutoMapper in what should initially be a pretty simple MVC project that I may have to spin up in the next month or two, as I've got some experience using Automapper in the project I mentioned a post or two ago. I found a pretty good refresher in this CodeProject post, but was a little surprised to find this observation from its author:
Wow, HEH-lo. Not a big deal for simple pages, but probably not something you want underpinning the architecture of an app that could grow (which is to say "any app that calls for MVC").
In other words, as this article entitled "Stop using AutoMapper in your Data Access Code" explains...
Obviously there are ways around this, namely making sure that the query that pulls your data only returns what you want for that specific data load, but then you're right back to my complaints about using a repository in the first place. Once you're hand-rolling optimizations, you've left the realm of reusable generic code. Stop trying to backport a square peg into a round hole.
DevTrends links to a post by Bogard that says:
Exactly. Though I'm not absolutely sure CQRS requires different sets of tables to gain the initial important architectural improvements I'm arguing for here.
No, I didn't know what CQRS was off-hand myself. It's apparently Command Query Responsibility Segregation. It's nice to see Martin Fowler essentially arguing the point from my previous post on ending conventional repository use for reads:
That said, Fowler's not quite so contra-CRUD as I am, and seems to believe there are many real-world use cases for C
I just don't see using CRUD as the best, scalable route to build even a typical MVC app.
Though Fowler seems less C
Just to be clear, I'm using CRUD with a bold "R" to indicate a conventional CRUD system, and C
There's also an implicit argument in Fowler that the write database would have a different model than the reporting dbms. I don't know that the extra overhead of two domains, one for write and one for read, is going to be worthwhile. I can understand the reporting server being a sort of "permanent temp table with periodic (and ad hoc) updates" setup, but you've still got to base it on the data that's on your write side.
That is, I don't see how you break out of C
Fowler's "hyper CQRS" with a reporting database is interesting, but, to me, moving to one or more reporting databases is a DevOps issue that's possible to insert well down the line, once you know reads are so out of proportion to writes that you need the support of another/distributed database servers -- a much easier move to accomplish in the future than ripping out an architecture based on Repository and automapping models. That is, you don't have to decide to use a reporting server when you hit File >>> New Project. You do need to decide not to get wrapped up with repositories and automapping.
Maybe we're similar things, just with Fowler giving more emphasis for the work as a unit rather than as many entities being affected as once. Just that, in my limited experience, optimizing writes (outside of batch-like use cases, but users seem conditioned to accept that they kick off batches and get notified when they're done) is rarely your primary performance bottleneck. Reads? That's what hobbles your systems seemingly anytime you're big enough that you're making money.
Getting back to automapping... The sum from the DevTrends post, above, is pretty good.
If your app has the potential to grow -- and let's just stipulate that any MVC app does -- you want to keep an eye on performance. And the more of this overhead you integrate into your architecture -- repositories, automapping in your data access layer -- the more tech debt you're going to have once that growth happens.
Anyhow, the tasks I was waiting on are done, so enough architecture discussion. Code time.
Bottom line: KISS now or you'll have debt to pay later.
posted by ruffin at 3/30/2015 11:12:00 AM
All posts can be accessed here:
Just the last year o' posts: