问题描述

所以，我需要一些输入来重构一个 asp.net (c#) 应用程序，它基本上是一个用于创建动态表单(任何表单)的框架.从高级的角度来看，有一个包含表单的表，然后有一个包含所有表单字段的表，两者之间是一对多.有一个验证表，每个字段可以有多种验证，从表单字段表到验证表是一对多的.

So, I need some input refactoring an asp.net (c#) application that is basically a framework for creating dynamic forms (any forms). From a high level point of view, there is a table that has the forms, and then there is a table that has all the form fields, where it is one to many between the two. There is a validation table, where each field can have multiple types of validation, and it is a one to many from the form fields table to the validation table.

所以问题在于，该应用程序已作为全方位可定制解决方案出售给所有客户.所以，这个想法是他们想要的任何形式，我们可以使用数据库配置来构建它.问题是，这并不总是可能的，因为领域之间存在复杂的关系，形式本身之间也存在复杂的关系.此外，只有一个代码库，这是针对多个客户的——所有客户都自己托管它.每个客户端都有非常具体的逻辑，它们都在同一个代码库中，没有真正的分离.有时使它成为通用的太难了，因此在某些情况下它具有硬编码逻辑(就像 formID = XXX 然后做 _ 一样).您还可以拥有嵌套表单，例如，每个表单中都有一组单独的字段.

So the issue is that this application has been sold as the be-all-end-all customizable solution to all the clients. So, the idea is whatever form they want, we can build it jsut using DB configurations. The thing is, that is not always possible, because there is complex relationship between the fields, and complex relationship between the forms themselves. Also, there is only once codebase, and this is for multiple clients - all of whom host it on their own. There is very specific logic for each of the clients, and they are ALL in the same codebase, with no real separation. Sometimes it was too difficult to make it generic, so there are instances where it has hard coded logic (as in if formID = XXX then do _). You can also have nested forms, as in, one set of fields on its own within each form.

所以通常，当一个客户端请求更改时，我们进行更改并将其部署到该客户端 - 但随后另一个客户端请求不同的更改，我们进行更改并将其部署到该客户端，但是来自客户端的更改较早的客户端破坏了它，尝试调试很头疼，因为一切都是动态的.我们无法回滚先前的更改，否则其他客户端会被搞砸.

So usually, when one client requests a change, we make the change and deploy it to that client - but then another client requests a different change, and we make the change and deploy it for THAT client, but the change from the earlier client breaks it, and its a headache trying to debug, because EVERYTHING is dynamic. There is no way we can rollback the earlier change, because then the other client would be screwed.

它不是在真正的 3 层架构中完成的——它是一个引用 DB 类和类库的网站.网站本身有业务逻辑，类库中有业务逻辑，数据库存储过程(验证在存储过程中完成).

Its not done in a real 3-tier architecture - its a web site with references to a DB class, and a class library. There is business logic in the web site itself, in the class library, and the database stored procs (Validation is done in the stored procs).

我负责重新组织整个事情，这些是我的想法/问题:

I've been put in charge of re-organizing the whole thing, and these are my thoughts/questions:

1. 我认为总的来说这是一个糟糕的模型，因为我听到一位开发人员说的一件事是，任何时候任何客户进行更改，我们都应该向所有人部署 - 但这不现实，如果我们已经说 20 个客户 - 需要对所有东西进行回归测试，因为我们不知道影响......

1. I think this is a bad model in general, because one of the things I heard one of the developers say is that anytime any client makes a change, we should deploy to everybody - but that is not realistic, if we have say 20 clients - there will need to be regression testing on EVERYTHING, since we don't know the impact...

总共有100个左右的形式，它们之间有一些相似之处(不多).但我认为动态引擎可以解决所有表单请求的想法也不现实.客户提出最奇怪的请求.例如，他们让这个引擎做一个常规的数据输入表单和一个搜索表单.

There are about 100 forms in total, and their is some similarity in them (not much). But I think the idea that a dynamic engine can solve ALL form requests was not realistic as well. Clients come up with the most weird requests. For example, they have this engine doing a regular data entry form AND a search form.

页面之间有很多保留状态，并且都是使用会话变量完成的，这没关系，只是它没有真正被跟踪，因此来自同一用户的会话不断被覆盖，我认为应该摆脱会话.

There is a lot of preserving state between pages, and it is all done using session variables, which is ok, except that it is not really tracked, and so sessions from the same user keep getting overwritten, and I think sessions should be got rid of.

我真的应该重写整个事情吗?这个应用程序大约有 3 年历史了，已经做了很多测试和事情，并且实现了严肃的业务逻辑，所以我不想摆脱所有这些(乔尔的建议).但它真的是一堆乱七八糟的代码，一切都需要很长时间才能完成，而且总是因为微小的变化而崩溃.

Should I really just rewrite the whole thing? This app is about 3 years old, and there has been lots of testing and things done, and serious business logic implemented, so I hate to get rid of all that (joel's advice). But its really a mess of a sphagetti code, and everything takes forever to do, and things break all the time because of minor changes.

我一直在阅读 Martin Fowlers重构"和 Michael Feathers有效处理遗留代码"——它们很好，但我觉得它们是为一个稍微"更好的架构的应用程序编写的，它仍然是一个 3 层架构，并且在逻辑上有一些"相似之处..

I've been reading Martin Fowlers "Refactoring" and Michael Feathers "working effectively with legacy code" - and they are good, but I feel they were written for an application that was 'slightly' better architected, where it is still a 3-tiered architecture, and there is 'some' resemblance of logic..

想法/输入任何人?

哦，还有帮助！"

推荐答案

我当前的项目听起来与您描述的产品几乎完全相同.幸运的是，我从以前的产品中学到了大部分最难的课程，因此我能够从头开始我的当前项目.您可能应该通读 我的回答这个问题，其中描述了我的经历和我学到的教训.

My current project sounds like almost exactly the same product you're describing. Fortunately, I learned most of my hardest lessons on a former product, and so I was able to start my current project with a clean slate. You should probably read through my answer to this question, which describes my experiences, and the lessons I learned.

需要重点关注的是您正在构建产品的想法.如果您无法找到一种使用当前产品功能集实现特定功能的方法，您需要花一些额外的时间思考如何将这个自定义的一次性功能变成一个可以使所有人受益的可配置功能(或在最少)您的客户.

The main thing to focus on is the idea that you are building a product. If you can't find a way to implement a particular feature using your current product feature set, you need to spend some additional time thinking about how you could turn this custom one-off feature into a configurable feature that can benefit all (or at least many) of your clients.

所以:

1. 如果您指的是能够创建一个完全可定制的表单，使特定于客户的代码几乎没有必要的模型，那么该模型是完全有效的，而且我有一个可维护的工作产品，并且有真实的付费客户可以证明这一点.回归测试是针对特定功能和配置组合进行的，而不是针对特定的客户端实现.使这成为可能的关键部分是:

1. If you're referring to the model of being able to create a fully customizable form that makes client-specific code almost unnecessary, that model is perfectly valid and I have a maintainable working product with real, paying clients that can prove it. Regression testing is performed on specific features and configuration combinations, rather than a specific client implementation. The key pieces that make this possible are:

1. 一个管理界面，可有效禁止有问题的配置选项组合.
2. 一个规则引擎，允许系统中的某些操作调用可自定义的触发器并导致其他操作发生.
3. 一个集成框架，允许从各种来源提取数据并以可配置的方式推送到各种来源.
4. 在绝对必要时将自定义代码作为插件注入的选项.

这篇关于asp.net c#中的动态表单创建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持编程学习网！