﻿<?xml version="1.0" encoding="utf-8"?><rss version="2.0"><channel><title>Ayende @ Rahien</title><link>http://ayende.com</link><description>Ayende @ Rahien</description><copyright>Copyright (C) Ayende Rahien  2004 - 2021 (c) 2026</copyright><ttl>60</ttl><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>See the post about testing NHibernate
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment20</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment20</guid><pubDate>Thu, 07 May 2009 21:58:44 GMT</pubDate></item><item><title>Johannes Rudolph commented on The Repository’s Daughter</title><description>Thank you for this very interesting disussion, I enjoyed it. Basically the point which is made here is something i had to learn the hard way.
  
  
I started working on a small company two years ago (i was 15) doing some kind of financial services. They had a LOB application based on Access DB's, 7 to be exact with identical schemas for 7 different clients. The application was .Net 2.0 with the famous "SQL in UI" pattern. The dev originally architecting this solultion left the company shortly before i entered. After fixing some serious bugs i soon realized the application wouldnt scale wiht future business requirements. So i started architecting a new solution based on a SQL Server.
  
  
After doing 2-3 Months of research my head was flooded with things like n-tier, SOA, DAL/Adapter etc. When I learned about Linq2Sql and the whole ORM thing i opted to go down this road. After basic prototyping and finishing my first "pseudo agile" iteration I learned about the repository pattern and started refactoring and using it instead of Linq2Sql directly in my controllers. The point of why I'm telling you all this is that this whole story is about the same point you made. 
  
  
I did (quite) randomly apply patterns and violated YAGNI, because i had absolutely no experience.
  
I was so damn scared of delving into a anti-DRY because of the experiences i made while maintaining the previous LOB application. Today i would not use repository pattern for this application but some kind of CQS, because the app is 1/3 about modifying data and 2/3 about querying.
  
  
@Ayende
  
Whats intriguing me is how you would approach testing without a repository which you can mock out? Do you mock ISession or use a SQLite Db? 
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment19</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment19</guid><pubDate>Thu, 07 May 2009 14:49:23 GMT</pubDate></item><item><title>Alex James commented on The Repository’s Daughter</title><description>Interesting stuff, I've found your ongoing debate with Greg very illuminating. Particularly timely too, I'm prepping for a TechEd talk, a big part of which is a discussion of Repositories.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment18</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment18</guid><pubDate>Wed, 29 Apr 2009 03:48:22 GMT</pubDate></item><item><title>Stephen commented on The Repository’s Daughter</title><description>Hmm, thanks Ayende- I've got some reading to do.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment17</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment17</guid><pubDate>Mon, 27 Apr 2009 11:12:38 GMT</pubDate></item><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>Stephen,
  
Take a look at designs based on document databased or key value stores.
  
  
As for the rest:
  
[ayende.com/.../Querying-is-a-business-concern.aspx](http://ayende.com/Blog/archive/2007/03/09/Querying-is-a-business-concern.aspx)</description><link>http://ayende.com/3978/the-repository-s-daughter#comment16</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment16</guid><pubDate>Mon, 27 Apr 2009 09:57:45 GMT</pubDate></item><item><title>Stephen commented on The Repository’s Daughter</title><description>Yes I see your point, I think behavior is generally more important when you want to add / modify / remove data, I just tend to find that when reading data, behavior is not so important- given that I assume correctness that the 'add / modify / remove' enforces.
  
  
But then if I have the conceptual model to write, modify and remove data (which will need to read most likely as well) I guess it becomes additional work to create a flatter model just to slightly better suit more 'read and compose' scenarios.
  
  
But it does make me wonder if there are any designs based on flatter conceptual models, and system behavior is simply defined in a different (more detached) way.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment15</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment15</guid><pubDate>Mon, 27 Apr 2009 09:38:16 GMT</pubDate></item><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>Stephen,
  
I am sorry, but while different requirement may have similar potential implementation, I generally classify them differently based on their purpose.
  
Your first example looked very much like something that I would want to use reporting / BI tools for. It looked like exploratory style of report to try to figure out to whom &amp; how we can sell more.
  
  
Reading your original comment with the new example, it make a lot more sense to me. But, an entity is rarely useful on its own, it is only meaningful in the context it exists in (the object graph that represent some business scenario).
  
Focusing on entities &amp; relations leads to a model that is very anemic. The question then becomes, where is the actual system behavior?
  
  
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment14</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment14</guid><pubDate>Mon, 27 Apr 2009 09:12:27 GMT</pubDate></item><item><title>Stephen commented on The Repository’s Daughter</title><description>Well it was just an example, a recent real query I've done in the last few days was that I wanted to display comments related to a certain element, I only wanted to display the top x comments, and only the comments of which were not suspended (or the owning user suspended).
  
  
Regardless if the feature sounds bizzare, thats the requirement- tools like linq to sql and the entity framework (even nhibernate) will handle these scenarios perfectly fine, I just need to hint to it how I'm going to use the data for it to be realistic (such as fetch strategy).
  
  
My point was that if I harshly abstract either of those technologies, I lose the ability to do any hinting on the calling side.. and may will end up with monolithic methods as described (which I just won't do).
  
  
Also the conceptual models rarely make sense when reading data, they make perfect sense when making changes to the data.. which was my point about having flat models that had no implicit properties for relations, but instead a simple syntax for explaining conceptual relations at query time.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment13</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment13</guid><pubDate>Mon, 27 Apr 2009 08:56:42 GMT</pubDate></item><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>Stephen,
  
What is the _purpose_ of using these types of queries. What you are talking about sounds like a report.
  
For a report, assuming there is not business logic, the easiest way to work with it is to use SQL and just bind a dataset to a grid.
  
If you are doing this for something that require business logic, then sure, that is different. But from the description, it sounded a lot more like report / BI than BL
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment12</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment12</guid><pubDate>Mon, 27 Apr 2009 07:42:14 GMT</pubDate></item><item><title>Stephen commented on The Repository’s Daughter</title><description>Ayende, If I had to write SQL every time I did a query like that I might as well not bother having any abstractions over my data and work straight with SqlConnection and whatever data object takes my fancy..
  
  
These kind of 'complex' queries aren't at all unusual in any website I build, surely I don't get to a point with a data abstraction like datamapping and repos where its 'nah too advanced' forget all of that and 'go raw'.
  
  
But greg I tried to find the video on cqs you suggested previously on codebetter, didn't manage but I'll do some research.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment11</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment11</guid><pubDate>Sun, 26 Apr 2009 17:19:35 GMT</pubDate></item><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>Greg,
  
I am not sure that I agree with the 90% figure, but I will go with it.
  
Also note that I am not even touching DDD, except the comment of not trying it unless you really mean it.
  
My comments are about data access as used in a vast number of applications.
  
Web apps are a part of that, but I am using the same approach for backend processing systems where the logic _is_ the system
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment10</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment10</guid><pubDate>Sun, 26 Apr 2009 15:31:01 GMT</pubDate></item><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>Victor,
  
No, think a service as in SOA. 
  
A service is one part of the business, and it encapsulate everything required to perform its operation.
  
Order Service
  
Shipping Service
  
Helpdesk Service
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment9</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment9</guid><pubDate>Sun, 26 Apr 2009 15:28:55 GMT</pubDate></item><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>Stephen,
  
What you are asking for is reporting. That is something that I would do with straight up SQL or OLAP.
  
No logic required.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment8</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment8</guid><pubDate>Sun, 26 Apr 2009 15:26:23 GMT</pubDate></item><item><title>Greg Young commented on The Repository’s Daughter</title><description>@Oren
  
  
It should be pointed out that 90% of what you discuss is web applications. I also hold the position that DDD should not be used as discussed in DDD on web applications (because they tend to be data centric and the boundaries are certainly quite different, a data tier for instance does not make much sense in most web architectures).
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment7</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment7</guid><pubDate>Sun, 26 Apr 2009 15:11:34 GMT</pubDate></item><item><title>Greg Young commented on The Repository’s Daughter</title><description>@Stephen that is *exactly* why one would want to use command and query separation... By using a separate layer we stop querying our conceptual domain model to build DTOs and instead just issue 1 off queries.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment6</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment6</guid><pubDate>Sun, 26 Apr 2009 15:09:26 GMT</pubDate></item><item><title>Victor Kornov commented on The Repository’s Daughter</title><description>You definition of "Servie" &amp; "Service Boundary" isn't clear from the post. Have I missed it? Understanding that will help a lot with grokking your whole point.
  
  
What you seem to imply is service spans multiple layers/classes/code files. Is that different from "vertical feature", i.e. a single concern that spans the app from UI to App controllers/servoces to Domain (if any) to DAL.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment5</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment5</guid><pubDate>Sun, 26 Apr 2009 15:07:59 GMT</pubDate></item><item><title>Chris Brandsma commented on The Repository’s Daughter</title><description>Actually, I've been enjoying this conversation quite a bit lately.  As the weakest part of my application api (I feel for my applications) is my repository code.
  
  
I keep switching between having one giant repository (that does everything the application needs) and multiple smaller repositories (that are mostly domain object specific).
  
  
But the actual methods in each repository (outside of GetById, List, Delete, and Save) is what truely varies.  They range from the standard four to hundreds.  So far I have not been able to resolve this completely (outside of doing linq magic in my presenters and services).
  
  
Bonus points: I only get to use NHibernate about half of the time.  Sometimes SubSonic, Entity Framework, Linq To Sql, or my own Fluent Ado.net (raw Ado.net calls).   My current standard works between all of those.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment4</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment4</guid><pubDate>Sun, 26 Apr 2009 14:55:00 GMT</pubDate></item><item><title>Stephen commented on The Repository’s Daughter</title><description>Personally reading all this at a conceptual level is just hurting my brain. I'd really like to see real world examples on both sides, even something as simple as 'customer with orders'.. and I want to get customers starting with 'S', ordered by how much they've spent, and I want the top five orders they've made in the last 6 months.. I sure as hell don't want to get 8 billion orders back and have that filtered in memory- and I also don't want a stupid method like:
  
 GetCustomersStartingWithAndOrderByTotalSpendageIncludingTopOrdersOverPeriod("s", 5, 6);
  
  
Because I honestly get the feeling thats what greg is expecting me to do in the real world..
  
  
To be perfectly honest I've lost faith in the whole conceptual model at the client.. I'd much rather prefer to have single entities and a way to describe their relationships when querying.. because in my reality, every query I do tends to have drastically different requirements about how related data is included and filtered.. of which using a conceptual model becomes really ugly.
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment3</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment3</guid><pubDate>Sun, 26 Apr 2009 14:51:50 GMT</pubDate></item><item><title>Ayende Rahien commented on The Repository’s Daughter</title><description>Robert,
  
The whole point of the discussion?
  
Traditional architecture with DL, BL, UI are not appropriate in many cases
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment2</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment2</guid><pubDate>Sun, 26 Apr 2009 14:20:28 GMT</pubDate></item><item><title>Robert M&amp;#252;hsig commented on The Repository’s Daughter</title><description>Very interesting discussion - could you show an example how you would create a typical application (with UI Layer, Business Layer &amp; Data Layer)?
  
Thank you very much
</description><link>http://ayende.com/3978/the-repository-s-daughter#comment1</link><guid>http://ayende.com/3978/the-repository-s-daughter#comment1</guid><pubDate>Sun, 26 Apr 2009 14:07:15 GMT</pubDate></item></channel></rss>