Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:Sigh. Stored procs in C# (Score 2) 318

OO is useful to a degree when it comes to database applications. However, there are a myriad of reasons hey you should push business logic into the database layer.

But before I get to these there is something to be said for implementing abstaction layers by providing interfaces and hiding implementations behind interfaces. You can thing of stored procedures and views in a database as just an interface layer between application components. When you do that, it becomes clear that stored procs and views are just another tool in the arsenal of a well rounded developer.

Back to why you might use views/stored procs. Let's start with complex applications environments. When you're dealing with multiple applications - some legacy, some new, written across a set of technologies - COM, JAVA, .Net, etc. - you cannot guarantee that libraries (if they exist/are comprehensive enough/are general in implementation) are reusable, much less properly reused. In this case it is best to plan for a single/manageable interface set based on views + stored procs you know you can maintain to abstract database schema changes from applications.

In database land you must have consistent, repeatable, up to date data. By housing business logic in the database, you expose to users standard views and procedures that ensure that consistency is maintained between inserts, updates, and deletes. Often these same mechanisms are used to prevent too much access to data. For example, you can preven value that are out of bounds based on expectations of business processes/relationships existing in your database.

Since databases house complex relationships (not uncommon to have to join across 5 tables to get the result you want), to think that the application layer should contain this complexity is to build a fragile system open to errors made by developers who do not fully understand the system, or if so make assumptions about what can/will change in future that are not property grounded.

Continuing, maintainability/business agility is increased with proper use of views/stored procs. If only code is used to access database information, it is much more difficult to update all the destops in your company when a database schema changes than it is to update the innards of a stored procedure with a well known interface. As such any logic that pertains specifically to reading/updating/deleting content from the database should at least be evaluated against a similar implementation that is in the database itself.

So with that you need to take C# in the database for what it is worth - it allows you more easily to define complex business logic (types, behaviors, interfaces) than the comparative T-SQL. As such it speeds development of database applications. It makes database maintenance easier by making the code more easily read/updated. It also lowers the bar to having good database logic by reducing the need for highly complex T-SQL. For these benefits there are drawbacks - portability, perf, etc.

As a professional developer/DBA it is up to you to be able to make these tradeoffs. It is not as simple as saying OO is the right way to go always - that's a purist's approach. Purists have issues in business environments where tradeoffs are required to achieve the expected objectives in the given amount of time and with the given set of resources.

Slashdot Top Deals

Technological progress has merely provided us with more efficient means for going backwards. -- Aldous Huxley