3

I am migrating an existing .NET 2.0, SQL Server codebase to a .NET 4.0, SQL Server 2008 environment.

The design pattern is that all app calls to the database go through a stored procedure. So there's a get[object name] stored procedure that needs to be created or altered for most select statements.

So the disadvantages of this architecture to me are already evident: inconvenience.

What are the advantages of this highly enforced stored procedure design? (now in .NET 4.0 as opposed to using an ORM).

Using ng-repeat on tbody appears to be valid see this post.

Also a quick test through an html validator allowed multiple tbody elements in the same table.

Update: As of at least Angular 1.2 there is an ng-repeat-start and ng-repeat-end to allow repeating a series of elements. See the documentation for more information and thanks to @Onite for the comment!

4

3 に答える 3

6

Actually - contrary to popular belief - performance isn't one of the advantages of stored procedures - not anymore. Properly written "inline" SQL queries with parameters are just as fast, get "compiled" once by SQL Server (before first use) and remain in the procedure cache of SQL Server just as long as any stored procedure.

But stored procedures do have advantages - two main ones I'd like to mention:

  1. the shield the user from the underlying tables. Which also means: it's another layer in your security system. Your database users do not need access to the tables - and thus they won't be able to cause any grief on those tables, either - by accessing them via Excel or Access or some other tool. This alone can be a huge benefit.

  2. the second point is having a layer of stored procedure can give your DBA a place to optimize. You as a developer only call stored procedures - and the DBA can tweak them, fine tune them, make them run faster. As long as the parameter list and the return result set remain the same - you as a frontend developer won't even notice (at least not in a negative way!)

于 2012-10-19T20:31:07.147 に答える
3

I take the approach of stored procs for INSERT/ UPDATE / DELETE for objects and do SELECTs in application code. Advantages:

  • Clear separation of business logic and data
  • Data security is better because it is controlled at the database layer.
  • Doing SELECTs in business logic is a compromise that anyone can read table data if they get the database login credentials, but they cant modify it (assuming you setup object level permissions correctly (tables read-only)), but i don't have to write a stored proc for every variant of where criteria.
  • its easier to customize data operations when you write your own data adapters vs ORMs
  • ORMs are fine, but there's typically alot of overhead in ORMs and i like the approach of my applications creating the least amount of work possible for the machines they run on. Plus I know exactly what is happening and there's less 'magic' happening behind the scenes

Disadvantages:

  • You can generate alot of code if you don't use ORMs, which means more to maintain.
  • It's fair to say that writing your own data adapters is re-inventing the wheel. more control always comes with a cost
于 2012-10-19T20:42:52.463 に答える
-3

ストアド プロシージャの最大のメリットは、実行時間です。「重い」SQL クエリがある場合は、SP を使用する必要があります。

于 2012-10-19T20:26:02.227 に答える