patching approach for asp.net site_问答_开发者

I'm working on a new project that is in .net 3.5.

Currently the client is using stored procs and we would really like to use LINQ to SQL instead. The main reason they use stored procs is because they believe they are easier to update and such, they dont use any special permissions or开发者_Python百科 such that I can see justify the use of stored procs over LINQ to SQL just they dont want to change.

I figure if I can present them a solution whereby they can easily deploy changes to the LINQ to SQL they might be more open to changing their mind.

As such I'm curious with an asp.net project (not mvc) how to go about updating the various assemblies that get created during the build process.

Say for instance all of my LINQ code is in a System.DataAccess project and that gets deployed to production, a prod bug then gets identified with the LINQ. How difficult is it to just deploy the changed DataAccess project (or rather any project that has had significant changes since the prod deployment).

One thing I'm not sure that will help the situation is that everytime there is a build the build number gets updated on all of the projects regardless of whether there was actually changes or not so just by looking at the version number of the projects would not be enough to determine the projects that need to be redeployed.

I'm not even sure if its possible to modify a build so only the changed projects have their version updated?

So basically I'm just curious as to the various patching processes out there and pros and cons (ie. requires iis reset etc).

Cheers

There are pros and cons for both.

SQL Stored Proc's are fast and efficient. You can do heavy SQL operations with a Stored proc which will execute way faster than anything you can do in Code, however it's another layer.

LINQ doesn't require as much maintenance work when a change occurs. It's easy to code against.

You will not need to reset IIS at all for any method. It's a good practice to update your assembly file versions for every release - only if you change code in that assembly. Upgrading versions just because will be messy and not needed.

Patching is easy with both. I find LINQ easier IMHO. If a table structure changes, I dont' need to modify stored procedures and the functions that use those stored procedures. It's a quick alter script, Your DBML should already be updated because you've been testing with the new version, then it's a deploy.

I always have my LINQ and partial data classes in the same assembly so it's a easy DDL release.

SQL Stored Procedures and LINQ-SQL are not mutually exclusive.

Generally for complex, greedy and resource-intenstive operations you still use SQL Stored Procedures (for example, an INSERT operation that relies on complex sub queries/db logic) and drag them onto the LINQ-SQL canvas.

In terms of patching - you can certainly then patch these Stored Procedures directly in SQL Server, and the LINQ-SQL classes dont need to be recompiled - as long as the signature doesnt change (params/return type).

In terms of updating version numbers from certain assemblies - not ideal. Gets very messy, may even cause problems (strong naming).

You should put all your DB logic/LINQ/CRUD operations in one assembly (DAL).

If you really want to isolate the LINQ logic and enable independant deployment of these assemblies - maybe you should consider partitioning your solution into web/app servers? I.e have your LINQ DAL Assembly and facade-like Assembly which exposes these operations on an application server, then your website on a seperate web server.

Depending on your architecture, you could then use either ASMX/WCF/.NET Remoting to faciliate calls between your web/app servers. (WCF doesnt work cross-domain).

Having said that, if you have your LINQ-SQL classes done right (good mix of simple LINQ CRUD operations, views, stored procedures), as mentioned you are still able to easily patch the stored procedures without affecting your application.