If you have a use case where the user is editing or adding a task - and they don't see or interact with other dependent tasks - then there's no problem (imo) having your DAL or database do the alterations on the dependent tasks when the user-edited task is saved.
On the other hand, if the dependent tasks are visible to the user as part of the use case, then wouldn't they expect to see the cascade effect on-screen? In that case I'd think you'd have the objects do the data changes so they are visible to the user immediately, and then they'd be saved to the database.
Personally
the only time I would consider putting business logic in DB is when this
approach would make a huge difference in performance. For example implementing
custom logic through business objects would involve fetching many thousands of
rows, updating one field in each one, and saving them one at a time (takes many
minutes and creates a ton of network traffic) vs. running one query in DB (takes
seconds or less).
Sergey Barskiy
Principal Consultant
office: 678.405.0687 |
mobile: 404.388.1899
Microsoft Worldwide Partner of the Year | Custom
Development Solutions, Technical Innovation
From: JonStonecash
[mailto:cslanet@lhotka.net]
Sent: Wednesday, September 30, 2009 12:32 PM
To: Sergey Barskiy
Subject: Re: [CSLA .NET] CSLA.NET in planning & scheduling system
All other things being equal, I would want to avoid putting
complex business logic into stored procedures. My primary motivation is
that it would be much easier to unit test the business logic in side of the BO
than in stored procedures. Without knowing all of the details, I would
guess that the scheduling logic would be in the collection object or (to
facilitate unit testing) a separate class that took a collection of the
scheduled business objects as an argument.
Jon Stonecash
Copyright (c) Marimer LLC