Ayende @ Rahien

Ayende Rahien commented on The DAL should go all the way to UI

Sat, 23 May 2009 10:30:53 GMT

Todd, No, you should avoid doing this sort of tasks in memory, the DB is much better at those sorts of things

Todd Behunin commented on The DAL should go all the way to UI

Fri, 22 May 2009 18:48:52 GMT

Thanks for this post - really enjoyed reading it! I too agree with the flexible querying up to the UI. However, that poses a question for me. Currently I'm using Linq2Sql as my DAL. Then in my Domain, I have some simple queries (returning IQueryable) which the UI will call and can also "extend" (paging, sort, etc.). Those queries will call the DAL (Linq2Sql), return a result set, and map those values to a separate Domain model, which types are exposed to the UI and get sent back up. Because I'm doing a mapping in the Domain, I'm essentially executing the query there, before it gets to the UI. Hence, if the UI were to "extend" any more on that query (sort, page, etc), that portion of the query wouldn't be executed in Sql but rather in the assembly itself. Therefore, I wouldn't get the performance benefits of sorting/paging in Sql Server. Is that typically ok though and a good design to follow?

Chris Nicola commented on The DAL should go all the way to UI

Tue, 19 May 2009 22:36:55 GMT

Thanks, I think this is starting to make some more sense to me. I am have to try to put all these ideas together in code and maybe build a sample application with it see if I am understanding the concept correctly. If I get something decent together I will post it up on CodeProject. Thanks, Chris

Ayende Rahien commented on The DAL should go all the way to UI

Tue, 19 May 2009 21:35:21 GMT

Chris, The session is created by infrastructure layer. The query is created by controller layer (not Controllers in MVC!) that manages the entire app.

Chris Nicola commented on The DAL should go all the way to UI

Tue, 19 May 2009 21:24:32 GMT

Interesting, sorry I feel like I am taking forever to fully understand this, but I do really want to make sure so I have one more clarification to ask of you. Where does the ISession object come from here, the business layer? Which layer manages the session object and which passes it to the query object? In other words where/when is the session created and what layer calls GetQuery(ISession session).

Ayende Rahien commented on The DAL should go all the way to UI

Tue, 19 May 2009 21:16:31 GMT

Chris, No, I will not. The PL will reference NH, will be able to affect queries, but it does not manage anything.

Chris Nicola commented on The DAL should go all the way to UI

Tue, 19 May 2009 19:46:16 GMT

So you allow the presentation layer to directly reference nHibernate, manage the session, call session.Save() directly etc.? The business layer then contains the domain/model entities, interfaces and also the query objects? My initial design had the data layer being the only layer that referenced nHibernate with a similar design to this: [www.codeproject.com/.../...rnateBestPractices.aspx](http://www.codeproject.com/KB/architecture/NHibernateBestPractices.aspx) I have started by just making a modification to the AbstractNHibernateDao .

Ayende Rahien commented on The DAL should go all the way to UI

Sat, 16 May 2009 04:26:24 GMT

The session is maintained by the infrastructure, a separate concept. I don't try to have an explicit DAL, NH does a great job in managing the data, I don't need a whole layer for that And yes, queries belong in the business layer. The presentation logic should have the ability to manipulate queries, yes. There should be some way for the presentation logic to get an instance of a query and execute it

Chris Nicola commented on The DAL should go all the way to UI

Fri, 15 May 2009 23:41:39 GMT

One more perhaps stupid question. What is supplying the session to the query object? Is it coming from the DAL? Is it instantiated by the presentation layer? Where is the session maintained?

Chris Nicola commented on The DAL should go all the way to UI

Fri, 15 May 2009 22:58:48 GMT

Sorry if this is a bit of a necro but I found this post very useful in explaining some hard questions I have been having with how best to work with nHibernate so thanks for that. Now in the diagram you have above how do you define the Business Layer vs. the DAL? Is the business layer the logic to return specific query results and the DAL just nHibernate? Now are you suggesting, if I am understanding, that the Presentation Layer should be able to have direct access to the DAL? I am assuming that the query object you have defined is something the Presentation layer can access and instantiate, correct? Finally, the query object you define, is it a part of the DAL or the Business Layer? Sorry if some of these questions seem a bit naive.

Gunnar Liljas commented on The DAL should go all the way to UI

Thu, 23 Apr 2009 18:43:00 GMT

"It is also, incidentally, wrong." That's a bit of a stretch, isn't it? Maybe a constructive provocation, though. I doubt we want the data access any closer to the UI, but rather the domain queryability. That is of course possible with in-memory Linq, but that's hardly useful in all scenarios, so I guess that it's actually "efficient domain queryability" that could be the goal. Just in case someone was offended by the "DAL to UI" bit... :)

Ayende Rahien commented on The DAL should go all the way to UI

Tue, 21 Apr 2009 07:39:17 GMT

Sergey, Linq to NH is production ready, yes. The one in the contrib. It doesn't support all scenarios, but it supports most of them

Ayende Rahien commented on The DAL should go all the way to UI

Tue, 21 Apr 2009 07:37:53 GMT

PaulBlmaire, Okay, that make sense, I wouldn't have thought that this would create such dramatic difference

Skep commented on The DAL should go all the way to UI

Tue, 21 Apr 2009 05:34:59 GMT

Ayende, We're not talking about complicated logic here..just additional data tasks that are directly related to persistance. Surely I don't need the overhead of a real service layer (and possibly another interface) just to invoke a sproc or to call method in another repository when my object is saved, do it? Are we getting into semantics here? Assuming that the session or the datacontext *is* my repository/data layer..if I call CustomerService.Save() instead of CustomerRepository.Save() even though both methods do exactly the same thing does that really change anything?

Ayende Rahien commented on The DAL should go all the way to UI

Tue, 21 Apr 2009 04:47:27 GMT

Skep, Yuck! Putting those kind of responsibilities in the data layer?

Skep commented on The DAL should go all the way to UI

Tue, 21 Apr 2009 04:13:36 GMT

I can definately see how this would eliminate a bunch of mindless repository query methods. But when it comes to persistance, it's hard to beat the flexibilty of a CustomerRepository.Save(customer). What if I need to perform some additional workflow steps after I persist it the object (but only if it's successful)? Or synch with another system? Or what if I need to populate some additional customer information, like looking up and setting some delinquency schedule.

Jérémie commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 15:37:17 GMT

I follow Sebastian [ayende.com/.../...should-go-all-the-way-to-ui.aspx](http://ayende.com/Blog/archive/2009/04/18/the-dal-should-go-all-the-way-to-ui.aspx#30325) Create a Query Layer sibbling to you domain layer. The query layer provides concerns about querying the domain using all necessary tooling (ordering paging). Data can come from replicated databases, precompiled database tables, cube...

Sergey Shishkin commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 14:52:08 GMT

@Ayende, That is approach that also like. Just a quick question. By saying "...how I approach data access using NHibernate", do you mean Linq2NH is production-ready? Which version do you use? That from NHContrib trunk?

Ayende Rahien commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 12:29:53 GMT

The difference is that if the requirement has changed, then we have a bug. In the scenario that I gave, the requirements haven't changed for the actual query, only what you want to do with it.

Jimmy Chan commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 12:17:33 GMT

Ayende, I still don't get it. You said: If the requirement have changed, then yes, I'll change this class. What the difference with changing this, GetInvoicesForUser(userId, pageNum, pageSize, orderByCol, orderByDesc) by adding column perhaps.. Change class - add property, change method - add column. Thanks.

Ayende Rahien commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 11:39:24 GMT

No, I don't mind that. However, we should make it clear what we are talking about when we talk about UI in this context, I am talking about the controller level, not whatever actually render the UI And sorry, no end to end sample :-(

Krzysztof Kozmic commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 11:27:16 GMT

So to be clear you do not mind having explicit reference to NHibernate in your UI assemblies and having explicit calls to NHibernate objects in your UI logic? Do you have an (even trivial) end-to-end sample for client application, (like the one on the screenshot) of that approach?

Peter Morris commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 10:46:44 GMT

I've never seen a DAL that the model uses, only a model that the DAL uses. What a strange approach.

Dirk commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 10:13:48 GMT

Aha I see so you stay within the Open/Closed principle by creating a new method for the query that would include the new param? So you are extending.

Ayende Rahien commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 10:08:01 GMT

Dirk, Why am I doing this? Usually, if I need to do this, there is a good business reason for this. And unless previous requirements have changed, I will not change this query, I'll create a new one. If the requirement have changed, then yes, I'll change this class.

Dirk commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 09:33:27 GMT

Whoops I meant violates Open closed!!

Dirk commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 09:32:43 GMT

I might have got the wrong end of the stick but here go's: If you had a new property that you need to add to the query you could extend the current implementation by adding that as a property to the class. but you would still need to update (not extend) the getQuery method to allow for the new property. So GetQuery is not closed for modification. an example: public class LatePayingCustomerQuery { public DateTime? DueDate {get;set;} public decimal? MinAmount {get;set;} public deciaml MaxAmount {get;set;} public DateTime? OverDueTime {get;set;} public IQueryable payment.DueDate >= DueDate.Value ); if(MinAmount != null) payments = payments.Where( payment => payment.Amount >= MinAmount.Value ); if(MaxAmount != null) payments = payments.Where( payment => payment.Amount <= MaxAmount.Value ); if(OverDueTime != null) payments = payments.Where( payment => payment.DueDate == OverDueTime .Value ); return from customer in s.Linq customer == payment.Customer ) select customer; } } So adding the OverDueTime param violates solid? Could get query iterate over its properties building th query dynamically? >

Ayende Rahien commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 09:10:54 GMT

Dirk, I am not sure that I understand what you mean here.

Dirk commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 09:07:55 GMT

Don't you still have to update the GetQuery method to reflect the newly extended properties?

Ayende Rahien commented on The DAL should go all the way to UI

Mon, 20 Apr 2009 08:23:54 GMT

Roger, I think that this would only cause more pain. We need too many assemblies as it is already.