Ayende @ Rahien

Tom Janssens commented on Flatten your architecture: Simplicity as a core value

Mon, 21 Mar 2011 14:54:02 GMT

I could not agree more with this post. After studying/using numerous lasagna code frameworks, and even building one myself, I think it is time to go back to basics. ( check [github.com/.../BeerEventModule.cs](https://github.com/ToJans/NerdBeers/blob/master/src/Org.NerdBeers/Org.NerdBeers.Web/Modules/BeerEventModule.cs) for a straightforward example). Most of my customers do not care whether their project is using some/the right kind of architecture or not, they just want a working product at a reasonable cost. So I usually start out with some kind of basic MVC/M-V-VM-model accessing the data directly from the controller. Since most queries are specific to a certain action in the controller anyway, there is no real value in abstracting them away in a repository. In fact, abstracting them away requires the dev to interpret yet another extra layer, and adds complexity/maintenance costs without extra added value. I am a big fan of YAGNI, and applying it to everything: I usually start on a project using duct-tape dev; only when the manual testing starts slowing me down, or the app is getting to complex, I start using AT/BDD, post-implementing the initial spec tests as well. If my controllers start getting to complex, I start abstracting functionality away into a domain service, using TDD if necessary. If this starts getting to complex, I switch everything to proper DDD, using the CQRS principles as a guideline (usually no eventsourcing and stuff, just the basic principles) ** Slightly off-topic rant **: In the end it is all about being pragmatic, and IMO in a lot of cases the software development industry is valuing form over function. A lot of the TDD fanatics seem to dislike the duct-tape first approach, but IMO their reasoning is a bit flawed: if you use TDD to guide your design, why don't you also write tests to verify whether your application's speed is sufficiently fast enough ? Their usual answer is: because it usually is fast enough, in the rare case the speed might be an issue, we implement a test for it. Well, if your design is pretty straightforward, then why would one need to drive it using tests ? Being an architecture junkie myself, and having made the mistake of overarchitecting things a numerous amount of times, I now call for simplicity. IMHO Getting to know the different forms of architecture or development methodologies is the easy part; knowing when to use them - and even more important: when not - is the hard part.

Kelvin Li commented on Flatten your architecture: Simplicity as a core value

Thu, 17 Mar 2011 15:51:35 GMT

This is all good if, 1. You are a one-man shop 2. Work on a small-scale project 3. Know the inside-out about NHibernate This is not good if, 1. You work in a team and people have different skill sets. You don't want front end developer to write arbitrary (crappy) queries 2. DBA don't allow direct access from DMZ 3. Work on a large projects

Ajai Shankar commented on Flatten your architecture: Simplicity as a core value

Thu, 10 Mar 2011 06:57:49 GMT

Duh You mean to say you can actually load crap from database through just Service/DataProvider/Repository/NHibernate! I always thought you needed a service bus and a boatload of WCF config and data contracts and view models sitting behind a facade on top of a service locator that wraps all dependency injection containers. So glad I do Django nowadays :) But using NHibernate directly may not be feasible if IT ops says no database access from the DMZ... Ajai

Chris Smith commented on Flatten your architecture: Simplicity as a core value

Tue, 08 Mar 2011 22:54:49 GMT

Excellent - agree entirely with the original article! Thanks for a refreshing view. This sounds like a hybrid of the Naked Objects pattern and CQRS. It works. I've used it successfully. It requires more discipline than piling on layers of abstraction which is key point. Most people lack discipline. If you have bad quality developers (which vastly outnumber the competent ones) or are one yourself, it will not work though. Also, lots of misquoted stuff on SoC. SoC is about clean abstraction (read SICP which predates all the design patterns guff). Your commands are already abstractions on the domain model and your queries are already abstracted by the ORM (providing you deal with aggregate roots properly etc). You do not need layers of facades and transfer objects to protect everything. Regarding extension and maintainability, refactoring late and massive extension is costly anyway and will affect scalability. Worry about it then when you can afford to (if you can't your business model sucks).

Francois Germain commented on Flatten your architecture: Simplicity as a core value

Mon, 07 Mar 2011 13:33:34 GMT

I tend to agree with you in many circumstances when the application is actually small scale or the backend is not going to be reused for integration scenarios and the like. For anything of decent size with true SOA and broader reach, write once, use anywhere type of backend, I am sure you agree that simplifying the architecture the way you describe it is near impossible and highly undesirable. Have a nice day! -f

Jarrett commented on Flatten your architecture: Simplicity as a core value

Fri, 04 Mar 2011 11:23:38 GMT

I've been doing this for about 6 months now. In my last two projects (ASP.NET MVC2&3), I've been injecting my ISession into my controller ctor. My business rules are on my domain models. (As opposed to anemic models or simple DTOs.) If I need to write a "service" (as in MVC action that returns XML or JSON), I use automapper to flatten objects. In my estimate, 90% of queries in an application are really simple (get by ID, get where Active = 1 and Customer ID = XXX). When they start getting complicated, I can easily create a spec and do session.Query

Tyler Burd commented on Flatten your architecture: Simplicity as a core value

Tue, 01 Mar 2011 17:24:04 GMT

@jdn in response to "Could you perhaps explain what the friction is?" We work on very large applications (far-reaching financial apps). These apps tend to have hundreds, if not thousands, of complex views (MVC Views, not DB Views). Writing views in the DB for a good chunk of those added a lot of time to the development cycle, and it cluttered the database. We saw no benefit to writing DB Views over writing queries directly in our codebase. It keeps us in one environment, we can use named queries, LINQ, HQL, Criteria, or raw SQL when appropriate, and we don't have a DBA griping at us for our use of thousands of views. It was also much easier to make changes to the model that might affect multiple queries; just search and replace for the HQL/SQL ones and you get free refactoring support with LINQ. We DO use some flattened tables to query against for performance reasons, but our apps are pretty write-heavy, so we can't go overboard with denormalizing data. The overhead to keep those tables in sync with the real, normalized data would soon grow to large, so we limit that practice to REALLY involved queries that span many tables and thus can't take advantage of our built-in indexes.

Nabeel commented on Flatten your architecture: Simplicity as a core value

Mon, 28 Feb 2011 10:37:12 GMT

Erich Gamma, coauthor of Design Patterns, answer these questions. In the following excerpt, Gamma is interviewed by Bill Venners. Venners: The GoF book [Design Patterns] says, “The key to maximizing reuse lies in anticipating new requirements and changes to existing requirements, and in designing your systems so they can evolve accordingly. To design a system so that it’s robust to such changes, you must consider how the system might need to change over its lifetime. A design that doesn’t take change into account risks major redesign in the future.” That seems contradictory to the XP philosophy. Gamma: It contradicts absolutely with XP. It says you should think ahead. You should speculate. You should speculate about flexibility. Well yes, I matured too and XP reminds us that it is expensive to speculate about flexibility, so I probably wouldn’t write this exactly this way anymore. To add flexibility, you really have to be able to justify it by a requirement. If you don’t have a requirement up front, then I wouldn’t put a hook for flexibility in my system up front. But I don’t think XP and [design] patterns are conflicting. It’s how you use patterns. The XP guys have patterns in their toolbox, it’s just that they refactor to the patterns once they need the flexibility. Whereas we said in the book ten years ago, no, you can also anticipate. You start your design and you use them there up-front. In your up-front design you use patterns, and the XP guys don’t do that. Venners: So what do the XP guys do first, if they don’t use patterns? They just write the code? Gamma: They write a test. Venners: Yes, they code up the test. And then when they implement it, they just implement the code to make the test work. Then when they look back, they refactor, and maybe implement a pattern? Gamma: Or when there’s a new requirement. I really like flexibility that’s requirement driven. That’s also what we do in Eclipse. When it comes to exposing more API, we do that on demand. We expose API gradually. When clients tell us, “Oh, I had to use or duplicate all these internal classes. I really don’t want to do that,” when we see the need, then we say, OK, we’ll make the investment of publishing this as an API, make it a commitment. So I really think about it in smaller steps, we do not want to commit to an API before its time.

Wayne Molina commented on Flatten your architecture: Simplicity as a core value

Sun, 27 Feb 2011 04:26:21 GMT

I am slightly confused about this. I understand the points Ayende is making, but unless I'm missing something it seems like he is advocating going back to the old WebForms way of just doing the data access code in the event handler (or controller, in MVC's case)? So having the controller itself set up the NHibernate query? I can't see how that's a good thing, I'm sorry. I understand your point about the other example being needlessly complex and YAGNI and all of that, but I can't imagine going back to the "dark ages" and just lumping all the code and stuff into the UI. I could maybe see a compromise and having a repository class or something to handle the actual NHibernate querying, and just expose that to the Controller e.g. var latestVisitation = visitationRepository.GetLatest(); and skip out on all the service layers (I admit I'm one of those developers that would have said the first example is a proper software design, properly abstracting things away an exposing only what is needed). I'm interested to see what others think, because I would argue vehemently that the method proposed is a step back, even for something as simple as querying some crap from the DB; with the more complicated architecture you have more flexibility to change things, or have very fine-grained control (for instance, the Repository exposes IQueryable and the Service exposes an actual List) over exactly what is returned. I do agree that can be very complex where it's not needed (in most situations do you really have go safeguard against another developer adding an item to what is meant to be a read-only list? Wouldn't it be easier to just say "Hey Bob this page exposes a read-only list" and trust Bob not to go and try to add things? I could certainly see adding a bunch of layers as guard clauses if you were writing a public API that others would be using, but for internal classes used by one application?)

Dropdigger commented on Flatten your architecture: Simplicity as a core value

Sat, 26 Feb 2011 18:09:41 GMT

In the real world there are two types of developers - the proper developers and the hackers. While the hackers just get things done and then regret later how they did it because it's not scalable and it wasn't properly planned to grow, the proper developers plan ahead and do things properly - and then still later regret how they did it when they find it's over complicated and convoluted, doesn't scale and is not future proof.

Nabeel Farid commented on Flatten your architecture: Simplicity as a core value

Fri, 25 Feb 2011 17:41:02 GMT

As a TDD Developer, for me, as long as one can write a good unit testable code (atmost 10-15 lines and I am pretty sure one can not write a good one without following SOLID or atleast the S ), there is no point of creating extra abstraction layers.

jdn commented on Flatten your architecture: Simplicity as a core value

Fri, 25 Feb 2011 00:20:55 GMT

@Tyler "we found that to create flattened views/tables for every screen or use case within the DB added a LOT of friction and overhead to the development process" Could you perhaps explain what the friction is? Is it related to how you use Resharper Templates? Creating flattened views/tables obviously requires more writing of code (it isn't something you can automate, not that I know of) but from a maintenance perspective, what I've been finding is that having specific custom view models that don't go through the 'write' domain model offsets that cost. I don't doubt your assertion, I'm just interested in getting other perspectives on how they view (pun intended) it. Thanks.

J commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 23:07:28 GMT

I use a class called DAO for simple CRUD operations. This class directly uses an ISession and is called by Controllers and occasionally the Presentation directly. If I need to do anything more complicated, I use an ISession directly in a Query Object. If I end up needing to change my persistence layer (doubt it), I can change the DAO to handle the basic CRUD operations. In all likelihood the complex queries would need to be re-written anyhow when using a different persistence layer. Just my two cents

JV commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 21:47:42 GMT

Tyler and I work together. He came up with all that stuff. It is awesome to work with and makes development so much easier. For being so great, I bought him some half-and-half for his coffee and let him fix my bugs this morning. :P

Rob commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 20:16:16 GMT

@Tyler Interesting, thanks.

Tyler Burd commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 20:04:22 GMT

@Rob: Well, knowing the formatting probably won't come through: We have an interface IFinder[EntityT, ArgsT] with one method: EntityT Find(ArgsT args); We also extend this to: ICollectionFinder[EntityT, ArgsT] : IFinder[ICollection[EntityT], ArgsT] This allows us to create finders like: UsersFinder : ICollectionFinder[SomeUserDTO, UsersFinderArgs] ICollection[SomeUserDTO] Find(UserFinderArgs args){...} where UsersFinderArgs would be a class containing all of the search parameters needed by the query, and possibly any desired paging info (pagesize, page number, etc.). We have a NullArgs singleton class for finders that don't need any arguments. In the Find method itself we query the db using ISession (passed in via IoC), usually using HQL or LINQ, sometimes raw SQL. We then generally use a ResultTransformer (I have one called DelegateResultTransformer that allows you to make the transformation inline instead of implementing a separate class) and return the DTOs. I use Resharper templates to make adding a new finder painless.

Rob commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 18:39:18 GMT

@Tyler Thanks for the response. That doesn't sound like over-abstraction at all. As your post demonstrates, it depends on the app/domain, right? Curious...what does a finder class look like? What responsibility does it have?

Tyler Burd commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 17:45:32 GMT

@Rob The projects that I work on tend to be very, very large (hundreds of different views, thousands of tables, etc.). It's not an overly-complicated system, but the domain is just that big. We do denormalize data and use some views where it makes our lives easier (or drastically improves read performance), but we found that to create flattened views/tables for every screen or use case within the DB added a LOT of friction and overhead to the development process. Additionally, our apps tend to be very write-heavy (not the norm, I know), so denormalizing the data at the DB level using triggers or indexed views was a big hit on performance. Encapsulating the queries within classes of their own allows us to use Views , HQL, LINQ, or Criteria where appropriate, and since the finder will always return the same flattened DTO it's easy to change out the method within the class. Even using raw SQL or views needs result transformation, though, so I would still want that encapsulated. I don't think it's over-abstraction. It's simply "Form/Controller needs data, Form/Controller calls Finder, Finder uses ISession directly and manages the querying and result transformation in whatever manner is appropriate, Form/Controller is kept very simple and knows only about the 'read' model". We can also then apply cross-cutting concerns to the finders (caching, logging, etc.). (sorry for the long reply)

Rob commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 17:23:42 GMT

@Tyler A bit off topic but I think that's where the "read model" from CQRS can come in handy. And not necessarily a different data store, at a basic level you can map to DB views or something similar. The light-switch moment for me was realizing the folly of trying to wrangle with NH to create the best query possible off of my domain. Why not just query exactly what you want, how you want (even raw sql), and leave the domain for writes and complex logic?

Tyler Burd commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 16:47:01 GMT

I've found that it's generally cleaner to encapsulate queries into their own Finder classes. One class per query, and this allows you to easily find where to make changes, add ResultTransformers, re-use the query elsewhere, etc., all without cluttering up the Controller class or anything else. Ayende, do you find that using the ISession directly within the controller, even when you have a complicated query with involved transformations adds significant clutter? I can see it working fine for simple scenarios, but when you get into large, variable queries that transform large data graphs it seems to me like it would become unwieldy...

jdn commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 16:26:43 GMT

You don't translate between the domain model and the view model. You just have a different model.

Jon Wingfield commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 14:55:27 GMT

"It's not about how the data is persisted or structured, it's about having different logical models for reading and writing, and how that gives us the ability (when we need it) to store our data differently for those different purposes." I agree. What I said about having a separate physical store isn't really correct. I do think that what you said about having different logical models IS necessary. I think that follows my statement about decoupling your View model from the Domain model. How can you go straight to Hibernate from your UI for reads and not have that coupled with your Domain model? The only way I see is to have another mapping layer between domain and data store, which is just moving the additional layer somethere else. IMO at the very least, you need a facade that translates from your Domain model to the View Model if you are going to have only one physical representation of the domain model.

Rob commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 14:45:36 GMT

The base principles of CQRS are very useful to most projects we encounter on a daily basis. However, the full implementation that most blogs seem to focus on lately include separate data stores for the read/write model, event sourcing, messages, esb, and on. The biggest issue with this new "hot topic" as it's portrayed in the blog world is that the full implementation has a great benefit for only the great minority of projects that most devs work on. People are pushing it like it's some sort of default architecture. I wish they would stop. But I digress....

J Healy commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 14:35:12 GMT

Rob, you beat me to it. Yes, separate read / write stores are not mandatory in CQRS. That said, most CQRS aficionados probably lean that way. I'm personally waiting for Oren to jump on the CQRS bandwagon just to see what he comes up with. Maybe a CobraQRS or something with RavenDB as the read store and Rhino Queues or RSB syncing the write and read stores.

jdn commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 14:29:00 GMT

Yeah, it depends on whether you do 'strict' CQRS (which is just about how you structure code) or take on the 'typical' architectural implementation of it.

Rob Ashton commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 12:54:27 GMT

". CQRS avoids this by having the query store be essentially in DTO format." That's not really true, an implementation when applying CQRS might do that but there is nothing to say you can't apply CQRS and still have your queries going against the single data store. It's not about how the data is persisted or structured, it's about having different logical models for reading and writing, and how that gives us the ability (when we need it) to store our data differently for those different purposes. IMO anyway.

Ayende Rahien commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 06:09:17 GMT

StanK, No, the UI directly talks to ISession, there is no need for additional abstraction

Jon Wingfield commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 04:20:20 GMT

I've been waiting to read this post since I noticed it queued a few days ago and it's not as "controversial" as I thought it would be... I don't think this is really CQRS, at least not my understanding of it. One thing in the demo posted above is the lack of separate command and query data stores. If you don't decouple your UI model from your object model, you're asking for trouble when you need to refactor. From a DDD standpoint, this is a glaring issue. Another issue it brings up (especially with NHibernate), is now you are blurring the lines of a session. Changes made to objects in the UI could be accidentally flushed and you end up detaching-reattching objects and messing around with StaleObjectExceptions. (We've had this exact problem on our project). IMO, the complete decoupling of View Model from Domain model is a must. CQRS avoids this by having the query store be essentially in DTO format.

mickyd commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 03:31:41 GMT

@Ayende so you reduced a well-designed-lose-coupled system to something that whilst arguably simpler, is considerably more likely to require more code changes becuase of tight-coupling. not to mention increased QA. so where does it stop? why dont you just have all your code in main( ) and be done with it? i suspect procedural programmers said the same thing when OO came about and compained about the overhead of the v-table. simplicity is only good for the short term, not for the long term. i would punch up "undo" if i were you

NC commented on Flatten your architecture: Simplicity as a core value

Thu, 24 Feb 2011 00:05:47 GMT

@Ayende 1) I have never seen such an effort succeed without a major re-write. So it doesn't really matter. In addition, YAGNI. ---- And as much as you think it cannot succeed without a major re-write, in some cases it's probably not possible to rewrite. I currently work on a project with two self-rolled ORMs with Services/Repositories properly interfaces that I'm currently replacing with NH, it's great that I can write a new Repo and change next to nothing else and everything works fine. In your example thats impossible.