Refactoring techniques for asp.net webforms application

You shouldn't need SQL Server to put an ASP.NET application online. If your site requires database persistence, then yes, you'll need SQL Server installed, but not necessarily on the same server. If your requirements were that "we need to deploy a website", then there's no indication that SQL Server would be a requirement, and I would not expect them to give you access. Many hosts, such as http://discountasp.net, provide hosting for ASP.NET applications and SQL Server databases completely separately.

One solution that you DO have is to host your ASP.NET application on the server of this company (assuming you're still on speaking terms), and host your SQL Server database on another machine somewhere completely different - they don't have to be on the same machine. Your web.config file will let you change your connection string so you can have them separately.

I don't know the specifics of the conversation, but unless you tell them that you specifically need SQL Server (though most web applications do have a database of some kind and you can pretty well assume it's needed), hosting companies still reserve the right to give/sell SQL Server separately. If you have admin access to your hosting machine, I would suggest just installing SQL Server Express unless you need some of the more serious SQL features. Most of the time the reason hosts sell SQL Server databases/install separately is the EXTREMELY hefty license price tag of the the non-express version.

I hope this helps, and leave a comment if I need to go into more detail in a particular area.

I don't think you are a million miles away from where you need to be.

What you need to do really depends on the level of abstraction that you need and what you foresee the future of this application to be.

You definitely do not want to be using multiple contexts in a single http request. That will cause you a lot of pain.

As a bare minimum I would alter your Engine to have the context dependency injected in (through the constructor or setter). That will allow you to isolate the engine for testing purposes by injecting in a mocked context.

I would then consider creating a BasePage class that new ups an Engine Instance in the constructor (passing in a new Context). Each subsequent page would then inherit from the BasePage and would therefore have an Engine instance by default.

I would then work on the Engine class to provide all the functionality that your pages require (possibly sub-classing if it starts to get a bit monolithic). You then make sure that all interaction between the UI and the underlying database is channelled through the Engine. This way you could extend the Engine as required say for instance Engine.Ajax.Get... or something along those lines.

Like I say the level of abstraction you require may reveal other design considerations that you will need to make. You may wish to implement a repository and unit of work pattern on top of the context (technically an EF context already gives you this but if you are not sure about sticking with EF or know that you will need to introduce alternative data access options then you will need to consider it).

If you are injecting dependencies and those dependencies are 'volatile' then you may look to use an Inversion of Control Container such as AutoFac or Windsor.