I'd like to know if anyone has used SQL SSIS packages to handle business rules/validation in their application workflow instead of placing all those rules inside business objects.
The goal in my dept has been to do all rules/validation in CSLA objects going forward. However, for a current large project kicking off, the idea has also floated about placing some business rules in SSIS packages. One of the arguments for this (by the DBAs) is that they can easily see where things go wrong.
Rhe discussion has also included the possibility of a hybrid approach -- placing rules in CSLA objects but utilizing those objects from within SSIS packages (either directly or by exposing those objects via services).
Any thoughts on the matter and things to consider? Thanks.
I've recently had the pleasure of working with some SSIS packages, and I can't say I've been too impressed with the development and debugging experience. I think my advice here would be to give some serious thought to what it's going to be like to support a solution like this, including (very important) *who* is going to be doing that support work.
If you've got DBA's who are interested in *owning* that part of the system, then I think it's only fair that their input be given a fair bit of weight, and if SSIS makes them more comfortable supporting that part of the system, then so be it.
For better or worse, though, my spidey-sense tells me that the DBA's want to be "involved", but they might not really believe that they're offering to be part of the front-line support team. I believe if you can clear up who's "involved" vs. who's "responsible", you might have a better basis to weight input like that.
This would also most likely prevent an n-level deployment of your application. Or would you rather create a command object in order to execute each rule?
Think WinRT and WindowsPhone that has no direct database access to SQL Server.
Your clients would most likely require direct database access in order to execute the rules.
Thanks to both for your input. We haven't made the final decision but your answers were helpful. The one other point influencing this discussion in my dept is what is most expedient right now. Certainly, the SSIS option is an "easier" route because that takes some of the load off the app developer and puts it onto the (willing) DBA. But the right answer for the long-term feels like objects for multiple reasons.
Copyright (c) Marimer LLC