将经典的ASP应用程序迁移到ASP.NET

时间:2022-05-15 01:41:41

We are in design phase of a project whose goal is replatforming an ASP classic application to ASP.Net 4.0. The system needs to be entirely web based. There are several new requirements for the new system that make this a challenging project:

我们正处于一个项目的设计阶段,其目标是将一个ASP经典应用程序重新放到ASP中。Net 4.0。系统需要完全基于web。新系统有几个新要求,使这成为一个具有挑战性的项目:

  1. The system needs to be database independent. It must, at version 1.0, support MS SQL Server, Oracle, MySQL, Postgres and DB2.

    系统需要独立于数据库。在1.0版本中,它必须支持MS SQL Server、Oracle、MySQL、Postgres和DB2。

  2. The system must be able to allow easy reporting from the database by third party reporting packages.

    该系统必须能够允许第三方报告包对数据库进行简单的报告。

  3. The system must allow an administrative end user to create their own tables in the database through the web based interface.

    系统必须允许管理最终用户通过基于web的界面在数据库中创建自己的表。

  4. The system must allow an administrative end user to design/configure a user interface (web based) where they can select tables and fields in the system (either our system's core tables or their own custom tables created in #3)

    系统必须允许管理最终用户设计/配置一个用户界面(基于web的),在那里他们可以选择系统中的表和字段(我们的系统核心表或他们自己在#3中创建的自定义表)

  5. The system must allow an administrative end user to create and maintain relationships between these custom created tables, and also between these tables and our system's core tables.

    系统必须允许管理最终用户在这些自定义创建的表之间,以及在这些表和系统的核心表之间创建和维护关系。

  6. The system must allow an administrative end user to create business rules that will enforce validation, show/hide UI elements, block certain actions based on the identity of specific users, specific user groups or privileges.

    系统必须允许管理最终用户创建业务规则,这些规则将强制验证、显示/隐藏UI元素、基于特定用户、特定用户组或特权的标识阻止某些操作。

Essentially it's a system that has some core ticket tracking functionality, but allows the end user to extend the interface, business rules and the database. Is this possible to build in a .Net, Web based environment? If so, what do you think the level of effort would be to get this done? We are currently a 6 person shop, with 2.5 full time developers.

本质上,它是一个具有一些核心票据跟踪功能的系统,但是允许最终用户扩展接口、业务规则和数据库。在。net中构建基于Web的环境,这可能吗?如果是这样的话,你认为完成这项工作的努力程度如何?我们目前是一个6人的商店,拥有2.5名全职开发人员。

5 个解决方案

#1


3  

One thing to question is who has created these requirements? Most experienced developers will have attenmpted a generic do-everything system in the past, most often without success. This is because it is a tricky thing to get right and there are a lot of pitfalls. Does the requirement for users to create their own tables at the database level come from an experienced programmer who understands security implications and design principles or is it from a project manager who has "done a bit of programming"? Get your real world requirements sorted out first.

有一个问题是谁创造了这些需求?大多数有经验的开发人员在过去都会注意到一个通用的“一切都做”系统,通常不会成功。这是因为这是一件棘手的事情,而且有很多陷阱。用户是否需要在数据库级别创建自己的表,这是来自一个有经验的程序员,他理解安全含义和设计原则,还是来自一个“做了一点编程”的项目经理?首先整理好你的真实需求。

Instead of

而不是

The system must allow an administrative end user to create their own tables in the database through the web based interface.

系统必须允许管理最终用户通过基于web的界面在数据库中创建自己的表。

Perhaps you should have the requirement

也许你应该有这个要求

The system must allow an administrative end user to define and store their own data through the web based interface.

系统必须允许管理最终用户通过基于web的接口定义和存储自己的数据。

This will stop you from narrowing your options. Brainstorm different implementations, create some prototypes and proff of concept designs and be prepared to throw these away.

这会阻止你缩小选择范围。对不同的实现进行头脑风暴,创建一些概念设计的原型和经验,并准备扔掉它们。

My approach would be to completely abstract the database access to the point where you might not really be creating new Client-defined tables in the datbase itself but rather virtual tables in your data access layer. This will help make the system database agnostic.

我的方法是将数据库访问完全抽象到这样的地步:您可能不是在datbase本身中创建新的客户端定义的表,而是在数据访问层中创建虚拟表。这将有助于使系统数据库不可知。

For validation, check out FluentValidation. It is a very easy-to use and flexible validation framework that works nicely with JQuery validation on the client side

对于验证,请检查FluentValidation。这是一个非常容易使用和灵活的验证框架,可以很好地在客户端使用JQuery验证

Give yourselves about a year, and then maybe add 50% for good measure. Really, estimating this kind of project is very difficult, but we have achieved a similar scale project with a similar team in a year using best practice agile methodolgy. I am assuming that your developers are competent. This is a very challenging project as you have rightly identified.

给自己大约一年的时间,然后再加上50%。实际上,估计这类项目是非常困难的,但是我们在使用敏捷方法的最佳实践中,已经在一年的时间内完成了一个类似的规模项目。我假定您的开发人员是有能力的。正如您正确地指出的那样,这是一个非常具有挑战性的项目。

#2


0  

It depends on the skill of the people doing the assignment. Give the requirements to the developers and try to get an estimate from them.

这取决于做作业的人的技能。向开发人员提供需求,并尝试得到他们的估计。

PS. please eleborate the question in the title of the question 'Can it be done' is a bit generic ;)

请在问题的标题中注明“可以完成吗?”这是一个有点通用的问题。

#3


0  

Yes, but for numbers like 3 and 5 why not use available software? Sun query tools, Ms sql management studuio, etc..

是的,但是对于像3和5这样的数字为什么不使用可用的软件呢?Sun查询工具,Ms sql管理studuio等。

#4


0  

You provided 6 questions/requirements and below is just my honest opinion.

你提供了6个问题/要求,以下是我的真实想法。

  1. Developing a system that has the ability to use a variety of DB backends is definitely possible and a nice approach.
  2. 开发一个能够使用各种DB后端的系统绝对是可能的,而且是一种很好的方法。
  3. Allowing read access into one of the DB backens for Reporting capabilities by Third party tools is a common scenario and possible.
  4. 允许第三方工具对数据库备份进行读访问,以实现报告功能,这是一种常见的场景,也是可能的。
  5. Allowing System administrators to modify DB structure (ie, add/edit/delete tables/colums) this is a questionable practice. Why recreate the wheel. Each of the Database Backends that you mentioned have administration tools built to manage the modification of database structures. More so if you plan to deploy this on the public internet then you open up the possiblility for disaster. If they are system administrators, why not just use the tools already created? Its safer, easier to develop, and in the end easier to support.
  6. 允许系统管理员修改DB结构(例如,添加/编辑/删除表/列),这是一个有问题的实践。为什么创建车轮。您提到的每个数据库后台都构建了管理工具来管理数据库结构的修改。更重要的是,如果你计划在公共互联网上部署它,那么你就为灾难打开了可能性。如果他们是系统管理员,为什么不使用已经创建的工具呢?它更安全,更容易开发,最终更容易支持。
  7. Allowing a enduser to configure an admin to configure the user interface by changing label names, hiding fields, requiring a field. This is not a problems on core tables but as for user defined tables see my comments on #3.
  8. 允许终端用户通过更改标签名、隐藏字段、需要字段来配置管理员来配置用户界面。这不是核心表上的问题,但是对于用户定义的表,请参阅我对#3的评论。
  9. Allowing admin to create and maintian relationships (ie foreign keys, primary keys, unique keys) from the web is just as dangerous and a pain in the butt as #3. Why recreate the wheel?
  10. 允许管理员创建和维护网络上的关系(即外键、主键、唯一键)和第3点一样危险和痛苦。为什么重现*?
  11. Your last question/requirement states alot. All I can say is start with allowing the user to customize the User Interface a little bit (hide/show fields, making a field required in a form). As for the rules engine, there are frameworks out there that handle rules/workfow. Perhaps some research on one of these frameworks would be helpful to you. Microsoft has Windows Workflow Foundation
  12. 你的最后一个问题/需求说明了很多。我只能说,首先允许用户对用户界面进行一些定制(隐藏/显示字段,创建表单所需的字段)。至于规则引擎,有一些框架可以处理规则/工作。也许对其中一个框架的一些研究会对你有帮助。微软有Windows工作流基础

Overall your not the first to come up with a these types of ideas. But the overall development and maintainability of an applicaiton like this could be a nightmare.

总的来说,你不是第一个想出这些点子的人。但是像这样的应用程序的总体开发和可维护性可能是一场噩梦。

#5


-1  

First off, yes all that can be done, but they aren't really requirements so much as implementation details. When you say an end use should be able to "create a new table," what you should say is "an end use should be able to define a new entity type." It doesn't necessarily have to have it's own table.

首先,是的,所有这些都可以完成,但是它们并不是真正的需求,而是实现细节。当你说终端使用应该能够“创建一个新的表”时,你应该说“终端使用应该能够定义一个新的实体类型”。它不一定要有自己的表。

Anyways, if you only have 2.5 developers (and I assume you are one of those), and you don't have enough experience to look at all the requirements and the current system and estimate the feasibility, then I don't think the project would be a success.

不管怎样,如果只有2.5个开发人员(我假设您是其中之一),并且您没有足够的经验来查看所有的需求和当前的系统,并估计其可行性,那么我不认为这个项目会成功。

#1


3  

One thing to question is who has created these requirements? Most experienced developers will have attenmpted a generic do-everything system in the past, most often without success. This is because it is a tricky thing to get right and there are a lot of pitfalls. Does the requirement for users to create their own tables at the database level come from an experienced programmer who understands security implications and design principles or is it from a project manager who has "done a bit of programming"? Get your real world requirements sorted out first.

有一个问题是谁创造了这些需求?大多数有经验的开发人员在过去都会注意到一个通用的“一切都做”系统,通常不会成功。这是因为这是一件棘手的事情,而且有很多陷阱。用户是否需要在数据库级别创建自己的表,这是来自一个有经验的程序员,他理解安全含义和设计原则,还是来自一个“做了一点编程”的项目经理?首先整理好你的真实需求。

Instead of

而不是

The system must allow an administrative end user to create their own tables in the database through the web based interface.

系统必须允许管理最终用户通过基于web的界面在数据库中创建自己的表。

Perhaps you should have the requirement

也许你应该有这个要求

The system must allow an administrative end user to define and store their own data through the web based interface.

系统必须允许管理最终用户通过基于web的接口定义和存储自己的数据。

This will stop you from narrowing your options. Brainstorm different implementations, create some prototypes and proff of concept designs and be prepared to throw these away.

这会阻止你缩小选择范围。对不同的实现进行头脑风暴,创建一些概念设计的原型和经验,并准备扔掉它们。

My approach would be to completely abstract the database access to the point where you might not really be creating new Client-defined tables in the datbase itself but rather virtual tables in your data access layer. This will help make the system database agnostic.

我的方法是将数据库访问完全抽象到这样的地步:您可能不是在datbase本身中创建新的客户端定义的表,而是在数据访问层中创建虚拟表。这将有助于使系统数据库不可知。

For validation, check out FluentValidation. It is a very easy-to use and flexible validation framework that works nicely with JQuery validation on the client side

对于验证,请检查FluentValidation。这是一个非常容易使用和灵活的验证框架,可以很好地在客户端使用JQuery验证

Give yourselves about a year, and then maybe add 50% for good measure. Really, estimating this kind of project is very difficult, but we have achieved a similar scale project with a similar team in a year using best practice agile methodolgy. I am assuming that your developers are competent. This is a very challenging project as you have rightly identified.

给自己大约一年的时间,然后再加上50%。实际上,估计这类项目是非常困难的,但是我们在使用敏捷方法的最佳实践中,已经在一年的时间内完成了一个类似的规模项目。我假定您的开发人员是有能力的。正如您正确地指出的那样,这是一个非常具有挑战性的项目。

#2


0  

It depends on the skill of the people doing the assignment. Give the requirements to the developers and try to get an estimate from them.

这取决于做作业的人的技能。向开发人员提供需求,并尝试得到他们的估计。

PS. please eleborate the question in the title of the question 'Can it be done' is a bit generic ;)

请在问题的标题中注明“可以完成吗?”这是一个有点通用的问题。

#3


0  

Yes, but for numbers like 3 and 5 why not use available software? Sun query tools, Ms sql management studuio, etc..

是的,但是对于像3和5这样的数字为什么不使用可用的软件呢?Sun查询工具,Ms sql管理studuio等。

#4


0  

You provided 6 questions/requirements and below is just my honest opinion.

你提供了6个问题/要求,以下是我的真实想法。

  1. Developing a system that has the ability to use a variety of DB backends is definitely possible and a nice approach.
  2. 开发一个能够使用各种DB后端的系统绝对是可能的,而且是一种很好的方法。
  3. Allowing read access into one of the DB backens for Reporting capabilities by Third party tools is a common scenario and possible.
  4. 允许第三方工具对数据库备份进行读访问,以实现报告功能,这是一种常见的场景,也是可能的。
  5. Allowing System administrators to modify DB structure (ie, add/edit/delete tables/colums) this is a questionable practice. Why recreate the wheel. Each of the Database Backends that you mentioned have administration tools built to manage the modification of database structures. More so if you plan to deploy this on the public internet then you open up the possiblility for disaster. If they are system administrators, why not just use the tools already created? Its safer, easier to develop, and in the end easier to support.
  6. 允许系统管理员修改DB结构(例如,添加/编辑/删除表/列),这是一个有问题的实践。为什么创建车轮。您提到的每个数据库后台都构建了管理工具来管理数据库结构的修改。更重要的是,如果你计划在公共互联网上部署它,那么你就为灾难打开了可能性。如果他们是系统管理员,为什么不使用已经创建的工具呢?它更安全,更容易开发,最终更容易支持。
  7. Allowing a enduser to configure an admin to configure the user interface by changing label names, hiding fields, requiring a field. This is not a problems on core tables but as for user defined tables see my comments on #3.
  8. 允许终端用户通过更改标签名、隐藏字段、需要字段来配置管理员来配置用户界面。这不是核心表上的问题,但是对于用户定义的表,请参阅我对#3的评论。
  9. Allowing admin to create and maintian relationships (ie foreign keys, primary keys, unique keys) from the web is just as dangerous and a pain in the butt as #3. Why recreate the wheel?
  10. 允许管理员创建和维护网络上的关系(即外键、主键、唯一键)和第3点一样危险和痛苦。为什么重现*?
  11. Your last question/requirement states alot. All I can say is start with allowing the user to customize the User Interface a little bit (hide/show fields, making a field required in a form). As for the rules engine, there are frameworks out there that handle rules/workfow. Perhaps some research on one of these frameworks would be helpful to you. Microsoft has Windows Workflow Foundation
  12. 你的最后一个问题/需求说明了很多。我只能说,首先允许用户对用户界面进行一些定制(隐藏/显示字段,创建表单所需的字段)。至于规则引擎,有一些框架可以处理规则/工作。也许对其中一个框架的一些研究会对你有帮助。微软有Windows工作流基础

Overall your not the first to come up with a these types of ideas. But the overall development and maintainability of an applicaiton like this could be a nightmare.

总的来说,你不是第一个想出这些点子的人。但是像这样的应用程序的总体开发和可维护性可能是一场噩梦。

#5


-1  

First off, yes all that can be done, but they aren't really requirements so much as implementation details. When you say an end use should be able to "create a new table," what you should say is "an end use should be able to define a new entity type." It doesn't necessarily have to have it's own table.

首先,是的,所有这些都可以完成,但是它们并不是真正的需求,而是实现细节。当你说终端使用应该能够“创建一个新的表”时,你应该说“终端使用应该能够定义一个新的实体类型”。它不一定要有自己的表。

Anyways, if you only have 2.5 developers (and I assume you are one of those), and you don't have enough experience to look at all the requirements and the current system and estimate the feasibility, then I don't think the project would be a success.

不管怎样,如果只有2.5个开发人员(我假设您是其中之一),并且您没有足够的经验来查看所有的需求和当前的系统,并估计其可行性,那么我不认为这个项目会成功。