在旧的胖客户端数据库上放置新的 Web 界面
我的公司有一个用 Delphi 编写的相当古老的胖客户端应用程序。我们非常有兴趣用一个闪亮的新 Web 应用程序替换它。这将使维护变得轻而易举，许多客户都需要 Web 应用程序。
该应用程序的领域知识极其丰富，其中一些知识是我们无法控制的。我们的客户使用该程序来管理自己的客户并向政府报告。所以一个不准确的程序是一个相当大的问题。旧程序没有测试。我们还不确定是否会使用新的测试来实施自动化测试。
我们首先计划基本上从头开始。但我们人手不足，基本上希望尽快让每个人都能上网。因此，我们决定尝试使用旧的胖客户端数据库，而不是从头开始。
数据库为SQL Server，可以方便地在SQL Server 2008中使用。它包含非常丰富的存储过程、函数、一些触发器和大量具有 80 多个列的表......但它已经相当规范化。我们希望 Web 应用程序和胖客户端都能够使用相同的数据库。这样，如果 Web 应用程序出现严重故障，我们的客户端仍然可以使用胖客户端并连接到我们的服务器。在 Web 应用程序被认为“稳定”之后，我们将弃用胖客户端。
还有其他人这样做过吗？您可以提供哪些建议？我们希望，在让每个人都访问网站后，慢慢改变数据库结构，以解决一些设计缺陷。将其保留在数据访问层中以便以后轻松进行更改的最佳方法是什么？
那么实际制作屏幕又如何呢？有没有比在 ASP.Net 中重写 80 个字段表单更简单的方法？有没有什么工具可以让这变得更容易？
目前的计划是使用 ASP.Net WebForms (.Net 3.5)。我真的很想使用 MVC，但团队中没有人知道它，包括我。
My company has a fairly old fat client application written in Delphi. We are very interested in replacing it with a shiny new web application. This will make maintenance a breeze and many clients want a web application.
The application is extremely rich in domain knowledge, some of which is out of our control. Our clients use the program to manage their own clients and report them to the government. So an inaccurate program is a pretty big thing. The old program has no tests. We are not sure yet if we will implement automated testing with the new one.
We first planned to basically start from scratch. But we are short handed and wanting to basically get everyone on the web as soon as possible. So instead of starting from scratch we've decided to try to make use of the legacy fat-client database.
The database is SQL Server and can be used in SQL Server 2008 easily. It is very rich in stored procedures, functions, a few triggers, and lots of tables with over 80 columns... But it is decently normalized. We want for both the web application and fat client to be capable of using the same database. This is so that if something breaks badly in the web application, our clients can still use the fat client and connect to our servers. After the web application is considered "stable", we'd deprecate the fat client.
Has anyone else done this? What tips can you give? We want to, after getting everyone on the website, to slowly change the database structure to take care of some design deficiencies. What is the best way to keep this in a data access layer so that later changes are easy?
And what about actually making the screens? Is there any way easier than just rewriting an 80 field form in ASP.Net? Are there any tools that can make this easier?
The current plan is to use ASP.Net WebForms (.Net 3.5). I'd really like to use MVC, but no one on the team knows it including me.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
实施自动化测试。用一个有缺陷的程序替换另一个有缺陷的程序有什么意义？
Implement automated testing. What's the point in replacing one buggy program with another?
好问题，但是让每个人都访问网站后“慢慢改变”数据库结构，听起来像个笑话......
我宁愿借此机会创建一个新的数据库结构，为您的数据库编写一个防弹迁移脚本，您可以尝试并重写无数次而不会对您的客户产生任何副作用，然后编写您想要的任何内容（fat/web ）在新数据库上进行测试，并在准备好后迁移所有人。
Good question, but "Slowly change" the db structure after getting everyone on the website, sounds like a joke...
I would rather take the opportunity to create a fresh db structure, write a bulletproof migration script for you db, that you can try out and rewrite a zillion times without any side effect fro your clients, and then write whaterver you want (fat/web) on the new db, have it tested and migrate everyone when it's ready.
我有几个建议：
1) 创建一个服务层来抽象掉对 DAL 的依赖。在您所描述的情况下，UI 和 BLL 依赖一个间接层可以使数据库更改更加安全。
2) 创建自动化测试（单元测试和集成测试），特别是如果您计划对域或持久层 (BLL/DAL) 进行相当重大的更改。为了使这变得非常简单，您应该始终尝试对接口进行编程。这使您的代码更加灵活，并允许您使用模拟框架（Moq 是我喜欢的一个）来确保您的测试真正是单元测试而不是集成测试。
3) 看一下 DDD (http://domaindrivendesign.org/)，因为它似乎非常适合给定的场景。至少有一些非常有用的模式可以帮助您的应用程序更加灵活。
4) MVC 一点也不难学，但是由于 MVC 架构（测试控制器而不是视图），它是一种获得 UI 单元测试设置的简单方法。也就是说，您没有理由不能对 Web 表单进行单元测试，只是需要做更多的工作。 MVC 实际上只是一个 UI 框架/设计模式（更多的是 Model2，但我们现在可以忽略它）。可以说，它让您更接近金属，因为您将编写更多 HTML 并使用模型（“M”）来传递数据。
对于 DDD，请查看 Eric Evans 的书：http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
希望有帮助
I have a couple suggestions:
1) create a service layer to abstract away the dependance on the DAL. In a situation as you describe having a layer of indirection for the UI and BLL to rely on makes DB changes much safer.
2) Create automated tests (both unit and integration), especially if you plan on making fairly significant changes to the Domain or Persistance layers (BLL/DAL). To make this really easy you should always try to program to an interface. This makes your code more flexible as well as letting you use mocking frameworks (Moq is one I like) to ensure your tests truely are unit tests and not integration tests.
3) Take a look at DDD (http://domaindrivendesign.org/) as it seems to fit pretty well with the given scenario. At the very least there are some very useful patterns that can help make your application more flexible.
4) MVC isnt very hard to learn at all, it is however an easy way to get unit testing setup for the UI as a result of the MVC architecture (testing the controller and not the view). That said, there is no reason you couldn't unit test web forms, its just a bit more work. MVC really is just a UI framework/design pattern (more Model2 but we can ignore that for now). It gets you closer to the metal so to speak as you will be writting a lot more HTML and using a Model (the 'M') for passing data around.
For DDD take a look at Eric Evans book: http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1317333430&sr=1-1
Hope that helps
ASP.NEt 表单是一个无用的东西，完全不适合这样的事情。我建议从在 30 分钟内为 StackOverflow 创建 OData API（包括 XML 和 JSON）之类的内容开始，然后在此基础上构建您的 Web 应用程序（即，将其推送到客户端，使用 JQuery/Silverlight）。
ASP.NEt forms is a no starter, is completely inappropriate for something like this. I recommend to start with something like Creating an OData API for StackOverflow including XML and JSON in 30 minutes, then build your Web app on top of that (ie. push it to the client, use JQuery/Silverlight).