请推荐一个将asp.net网站迁移到三层架构的方案
我构建了一个 ASP.NET 网站，该网站的规模和复杂性都显着增长。我一开始没有创建 DAL 或 BLL，因为我是新手，并且认为这对我来说更简单。相反，我使用了大量的 SqlDataSource，并将所有业务逻辑放在相关页面的代码隐藏中。这是一项艰巨的学习项目。但随着时间的推移，我一直在稳步添加功能，同时该网站的使用量也显着增长。我现在发现自己的一些东西变得难以维护。一定要进行一些重构。
我想做的是开始分离我的 UI、业务逻辑和数据访问代码。我拿起福勒的一本书，并且在网上阅读了足够的内容，知道这是一件好事。我的问题是，大多数示例和教程都假设读者是从头开始的。我需要制定一个计划来有条不紊地完成这一任务。我需要以一种让我能够继续学习和培养技能的方式来做到这一点。
因此，以所有这些为背景，我的问题是如何将这项任务分解为小块？例如，我应该首先用新层替换所有这些 SQLDataSource 控件吗？或者，我应该从创建一些存储过程开始吗？或者也许我应该首先迁移到 Linq。您现在可能已经明白了。我正在寻找的是一个答案，它规定了一系列小的增量步骤，我可以将其用作我的路线图。谢谢！
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 incremental steps that I can use as my roadmap. Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我不会从 DAL 开始，这样你的代码可能不会变得更清晰，但你必须实现整个 DAL 基础结构并将其与你的 asp.net 代码绑定，这是很多工作。理想的方法是从单元测试开始，但我认为如果您的代码组织得不好，那么事情就不那么容易了。
我会尝试首先将业务逻辑提取到单独的层，这将要求您像从头开始构建一样思考。我敢打赌，这会让您想要在此过程中进行更多重构。您可以首先创建一个单独的类库项目，然后开始使用所需的所有数据访问代码提取逻辑。
当你的 UI 层除了表示逻辑之外没有任何东西时，那么就该重构你的新 BLL 了。为您的 DAL（例如工作单元）选择正确的抽象，以便您可以轻松编写单元和集成测试。
然后写很多测试。然后你就准备好真正开始重构你的代码了:)
重点是不要尝试从一开始就立即执行太多重构，只需移动代码以使所有内容更加清晰和分离。在这种情况下，总会涉及一些思维转变。
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.
首先创建一个 DAL 层，将所有查询放入其中，然后将所有数据访问代码移至该层。稍后您可以根据复杂性决定是否使用存储过程等。将其与您当前的 UI（也有业务代码）集成以检查一切是否正常。确保您有正确的代码来处理连接和对象。
然后将所有业务逻辑代码移至您的 BAL。
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.
从架构的角度来看，您可以分解代码以使用 MVC 模式：
例子。
他们通信的方式是，您的控制器将处理从数据访问层检索的数据（例如：进行一些计算等），然后控制器将这些值传递给（绑定）视图，或者简单地说：数据访问层<--->控制器<---> view
以下是关于如何根据上述计划重构代码的一些提示：
虽然你可能无法模拟一切
根据你的描述，代码似乎是紧密耦合的。制作
确保单元测试通过您需要的所有情况。
接入层。如有必要，更新您的单元测试并再次运行它们
确保您的更改不会导致任何错误。
这是你的控制器层。更新您的单元测试（如果您进行单元测试
用户界面）。
控制器层遵循OO原则。你可以使用一些设计
模式使您的代码耦合性降低且可扩展性更强，因此如果
你以后必须添加一些东西，它们不会影响你的
现有代码。然后更新您的单元测试并确保它们通过。
在重构之前进行单元测试非常重要，以确保您的更改不会破坏代码和/或产生新的错误。
谢谢。
From the architectural point of view, you can break down your code to use MVC pattern:
example.
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:
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.
access layer. Update your unit tests if necessary and run them again
to make sure your changes don't cause any error.
this your controller layer. Update your unit tests (if you unit test
the UI).
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.