Please recommend a plan for migrating asp.net website to a three-layer architecture_问答_开发者

I have an ASP.NET website that I built that has grown considerably in size and complexity. I did not create a DAL or BLL in the beginning because I was a newbie and decided that was simpler for me. Instead I used a lot of SqlDataSources and put all of the business logic in the code-behinds for the relevant pages. It was one heck of a learning project. But over time I've steadily added features all the while usage of the site has grown significantly. I now find myself with something that has become unwieldy to maintain. Some refactoring is definitely in order.

What I would like to do is to begin separating my UI, business logic and data access code. I picked up a book by Fowler and have also read enough online to know that this is a good thing to do. My trouble is that most examples and tutorials assume the reader is starting from scratch. I need to put together a plan to accomplish this methodically. And I need to do this in a manner that allows me to continue to learn and build skills as I go.

So with all of that as context, my question is how do I break this task down into bite-size chunks? For example, should I start by replacing all of those SQLDataSource controls with a new layer? Or, should I start by creating some stored procs? Or maybe I should migrate first to Linq. You probably get the idea by now. What I'm looking for is an answer that prescribes a sequence of small i开发者_C百科ncremental steps that I can use as my roadmap. Thanks!

I wouldn't start with DAL, your code probably won't become much clearer this way but you'd have to implement the whole DAL infrastructure and bind it with your asp.net code, a lot of work. The ideal way would be to start with unit tests but I suppose it's not as easy if your code isn't organized well.

I'd try to extract business logic to separate layer first, this will require you to think like you're building from scratch. And I bet it'll make you want to refactor a lot more in the process. You can start by creating a separate Class Library project and start to extract logic with all data access code required.

When your UI layer is free from everything but presentation logic, then it's time to refactor your new BLL. Choose the right abstraction for your DAL (for ex. Unit of work), so you could easily write Unit and Integration Tests.

Then write a lot of Tests. And then you're ready to really start to refactor your code :)

The point is don't try to perform too much refactoring at once from the start, just move the code around to make everything more clear and separated. A little mind-shift is always involved in such scenarios.

Start off by creating a DAL layer, having all the queries in there and then move all your data access code to that. Later you can decide depending on the complexity whether to use stored procs, etc. Integrate that with your current UI(which also has the business code) to check all is fine. make sure you have proper code to handle connections and objects.

Then move all the business logic code to your BAL.

From the architectural point of view, you can break down your code to use MVC pattern:

Put your SQL stuff in your data access layer, you can use EF for example.
Put your logic stuff in the controller layer.
Put all of your UI controls/views in the view layer.

The way they are going to communicate is, your controllers will process the data retrieved from data access layer (e.g.: do some calculation, etc), then the controllers will pass those values to the (bound) views, or simply put: data access layer <---> controller <---> view

Here are some hints on how to refactor your code based on the above plan:

First of all, create some unit tests from the existing code, even though you probably wouldn't be able to mock up everything as from your description, it seems that the code are tightly coupled. Make sure that the unit tests pass all of the cases you need.
Second, separate your SQL query stuff from your logic to your data access layer. Update your unit tests if necessary and run them again to make sure your changes don't cause any error.
Third, separate your logic from your views (UI stuff). We'll call this your controller layer. Update your unit tests (if you unit test the UI).
Last but not least, you need to refactor the business logic stuff in the controller layer to follow OO Principles. You can use some design patterns to make your code less coupled and more extensible, so if you have to add some stuff in the future, they won't affect your existing code. Then update your unit tests and make sure they pass.

Having unit tests is very important before refactorring to make sure your changes don't break the code and/or create new bugs.

Thanks.