﻿<?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>Sneal commented on Reporting business logic</title><description>What about using the .NET 2.0 ReportViewer control?  It allows to use classes as data sources which sounds like what you need.
</description><link>http://ayende.com/2221/reporting-business-logic#comment5</link><guid>http://ayende.com/2221/reporting-business-logic#comment5</guid><pubDate>Sun, 18 Mar 2007 18:54:21 GMT</pubDate></item><item><title>Ayende Rahien commented on Reporting business logic</title><description>The specs information is in the database.
  
The problem that I have with it is that there is significant business logic in spanning a spec to a calendar. It is extremely non trivial, and I would really hate to try doing it in the database.
</description><link>http://ayende.com/2221/reporting-business-logic#comment4</link><guid>http://ayende.com/2221/reporting-business-logic#comment4</guid><pubDate>Fri, 16 Mar 2007 19:07:51 GMT</pubDate></item><item><title>jagid commented on Reporting business logic</title><description>In the past  have produced this type of report using analytical functions in Oracle. SQL Server 2005 also supports these but they are not as extensive (don't know whether they can support what you would need here). I know that you said that the data does not exist in the database but there's no reason why you can't put it there to report on.
</description><link>http://ayende.com/2221/reporting-business-logic#comment3</link><guid>http://ayende.com/2221/reporting-business-logic#comment3</guid><pubDate>Fri, 16 Mar 2007 19:04:58 GMT</pubDate></item><item><title>Ayende Rahien commented on Reporting business logic</title><description>@Roberto,
  
The AppointmentSpec can change, this means that I can create a perfectly valid appointment, and then change the AppointmentSpec so it is no longer valid.
  
Spanning the AppointmentSpec is costly in terms of CPU, so I would like to avoid that if possible. Trying to pre-validate would mean that quite a few scenarios would need to do this validation.
  
</description><link>http://ayende.com/2221/reporting-business-logic#comment2</link><guid>http://ayende.com/2221/reporting-business-logic#comment2</guid><pubDate>Fri, 16 Mar 2007 17:47:07 GMT</pubDate></item><item><title>Roberto Messora commented on Reporting business logic</title><description>first idea after reading: you can track with a sort of flag (or state) if the appointment differ from the spec in the moment of creation or in the moment of change, so your search is limited only to the appointment with the flag raised.
  
i mean you could be proactive and not reactive, but I don't know if this will involve an overload of "validation"
  
Roberto
</description><link>http://ayende.com/2221/reporting-business-logic#comment1</link><guid>http://ayende.com/2221/reporting-business-logic#comment1</guid><pubDate>Fri, 16 Mar 2007 17:12:32 GMT</pubDate></item></channel></rss>