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

有一个问题是谁创造了这些需求?大多数有经验的开发人员在过去都会参加一个通用的无所不能系统,大多数情况下都没有成功。这是因为这是一个棘手的事情,得到正确的,有很多陷阱。用户在数据库级别创建自己的表的要求是来自一个了解安全含义和设计原则的有经验的程序员,还是来自一个“做了一点编程”的项目经理?首先理清现实世界的需求。

而不是

管理最终用户 他们在数据库中自己的表

也许你应该有这个要求

系统必须允许 定义和 存储自己的数据 通过网络 基于接口。

这将阻止你缩小你的选择范围。头脑风暴不同的实现,创建一些原型和概念设计的形式,并准备扔掉这些。

我的方法是将数据库访问完全抽象到这样一个点,即您可能不会真正在数据库本身中创建新的客户机定义的表,而是在数据访问层中创建虚拟表。这将有助于使系统数据库不可知。

要验证,请查看 FluentValidation

给自己一年左右的时间,然后再加50%作为衡量标准。实际上,估计这类项目是非常困难的,但是我们使用最佳实践敏捷方法在一年内与一个类似的团队完成了一个类似规模的项目。我假设你们的开发人员是有能力的。这是一个非常具有挑战性的项目,正如你正确地指出的。

这取决于做作业的人的技能。把需求交给开发人员,试着从他们那里得到一个估计。

另外,请把题目中的问题删去,题目“能做到吗”有点泛化;)

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

你提供了6个问题/要求,下面是我的真实意见。

1. 开发一个能够使用各种数据库后端的系统绝对是可能的,也是一个不错的方法。
2. 允许第三方工具对其中一个DB backen进行读访问以获得报告功能是一种常见的情况,也是可能的。
3. 允许系统管理员修改数据库结构(即,添加/编辑/删除表/列)这是一个值得怀疑的做法。为什么要重现轮子。您提到的每个数据库后端都构建了管理工具来管理对数据库结构的修改。更重要的是,如果你计划在公共互联网上部署它,那么你就打开了灾难的可能性。如果他们是系统管理员,为什么不直接使用已经创建的工具呢?它更安全,更容易开发,最终更容易支持。
4. 允许最终用户通过更改标签名称、隐藏字段、需要字段来配置管理员以配置用户界面。这在核心表上不是一个问题,但对于用户定义的表,请参阅我在#3上的注释。
6. 你的最后一个问题/要求说明了很多。我只能说,首先允许用户自定义一点用户界面(隐藏/显示字段,使表单中需要一个字段)。至于规则引擎,有一些框架可以处理规则/工作流。也许对其中一个框架进行一些研究会对您有所帮助。Microsoft有Windows Workflow Foundation

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

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