动态表单创建在asp.net c＃ [英] Dynamic form creation in asp.net c#

问题描述

因此，我需要一些输入重构一个基本上是创建动态表单（任何形式）的框架的asp.net（c＃）应用程序。从高层次的角度来看，有一个表格具有表单，然后有一个表格具有所有的表单字段，它们之间是一对多的。有一个验证表，每个字段可以有多种类型的验证，它是从表单字段表到验证表中的一个到多个。

所以问题是这个应用程序作为全面可定制的解决方案被销售给所有的客户端。所以，这个想法是他们想要的任何形式，我们可以使用DB配置来构建它的jsut。事情是，这并不总是可能的，因为领域之间有复杂的关系，形式本身之间的复杂关系。此外，只有一个代码库，而且这是为多个客户端 - 所有这些客户端都是自己托管的。每个客户端都有非常具体的逻辑，并且它们都在同一个代码库中，而不是真正的分离。有时候它是非常困难的，使它成为通用的，所以有一些情况下，它有硬编码逻辑（如在formID = XXX然后做 _ ）。您也可以在每个表单中拥有自己的一组字段中的嵌套表单。

所以通常，当一个客户端请求更改时，我们进行更改并将其部署到该客户端 - 但是另一个客户端请求不同的更改，我们进行更改并将其部署为该客户端，但是从较早的客户端的更改将会破坏它，并且会令您头痛尝试调试，因为一切都是动态的。没有办法我们可以回滚早期的改变，因为那个其他的客户端会被拧紧。

它不是在真正的3层架构中完成的 - 它的一个网站引用了一个DB类和一个类库。在网站本身，类库中存在业务逻辑，数据库存储过程（验证在存储过程中完成）。

我已经被负责重组整个事情，这些是我的想法/问题：

1. 我认为这是一个坏的模型一般来说，因为我听说有一位开发人员说，任何一个客户端都可以随时改变，所以我们应该向所有人部署 - 但是如果我们说20个客户端，那就需要进行回归测试因为我们不知道影响...




2. 总共有大约100种形式，他们是一些相似之处（没有太多）。但我认为动态引擎可以解决所有表单请求的想法也不现实。客户想出了最奇怪的请求。例如，他们有这个引擎做一个常规的数据输入表单和一个搜索表单。




3. 页面之间有很多保留状态，它们都是完成使用会话变量，这是好的，除了它没有被真正的跟踪，所以同一个用户的会话不断被覆盖，我认为会话应该摆脱。


我应该只是重写整件事吗？这个程序大概是3岁，已经做了大量的测试和工作，并且实施了严肃的业务逻辑，所以我讨厌摆脱所有这些（joel的建议）。但是，它真的是一串sphagetti代码，一切都需要永远的事情，事情因为微小的变化而一直在休息。

我一直在阅读Martin Fowlers重构和Michael Feathers有效地使用遗留代码 - 而且他们很好，但是我觉得他们是为一个应用程序编写的，这个应用程序是稍微更好的架构，仍然是一个三层架构，而且有一些逻辑相似。

想法/输入任何人？

哦，和帮助！

解决方案

我目前的项目听起来和你描述的几乎完全相同的产品。幸运的是，我学到了大部分我以前的产品最难的课程，所以我能够用干净的平板电脑开始我目前的项目。您应该阅读我的回答这个问题，其中描述了我的经验，以及我学到的经验教训。

主要关注的是您正在构建一个产品。如果您找不到使用当前产品功能集实现特定功能的方法，则需要花费更多时间考虑如何将此自定义一次性功能转换为可以使所有（或在至少很多）您的客户。

所以：

1. 如果你是指的是能够创建一个完全可定制的表单，使客户端特定代码几乎不必要的模型，该模型是完全有效的，我有一个可维护的工作产品与真正的付费客户端可以证明它。对特定功能和配置组合执行回归测试，而不是特定的客户端实现。这样做的关键是：
   
   
   
   
   1. 一个管理界面，有效地禁止配置选项的有问题的组合。
   
   
   2. 一个规则引擎，允许系统中的某些操作调用可定制的触发器，并导致其他操作发生。
   
   
   3. 一个集成框架，允许从各种来源提取数据并推送
   
   
   4. 在绝对必要时将自定义代码注入插件的选项。
   
   



2. 是的，客户端提出了奇怪的请求。建议替代解决方案通常是值得的，这些解决方案仍然可以解决客户端的问题，同时仍然允许您的产品对其他客户端进行强大的配置。有时你只需要推回。其他时候，你必须做他们所说的，但是使用明智的架构做法来最大限度地减少对其他客户端代码的影响。


3. 尽量减少会话跟踪状态。每个页面都应该有足够的信息来跟踪当前页面的状态。即使用户点击返回并开始执行其他操作也需要保留的信息应存储在数据库中。但是，我发现在会话中保留一种面包屑树，以便跟踪用户到达某个特定地点以及在完成时将其重新置于何处。但是，实际上它们实际上的节点的ID现在需要逐页保持，并且每个请求发回来，所以当用户浏览不同页面的不同标签时，奇怪的事情不会发生。


4. 使用增量重构。您可能会在完成之后重新整理两次，或者您可能永远不会完成重构。但与此同时，一切仍然会奏效，而且您会经常出现新功能。一般来说，重写整个事情会让你多次，只要你认为这样做，所以不要试图把所有的东西放在一个叮咬。

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.

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.

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. 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...

2. 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.

3. 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.

4. 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.

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..

Thoughts/input anyone?

Oh, and "Help!"

解决方案

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.

So:

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. An administrative interface that is effective at disallowing problematic combinations of configuration options.
   2. A rules engine that allows certain actions in the system to invoke customizable triggers and cause other actions to happen.
   3. An Integration framework that allows data to be pulled from a variety of sources and pushed to a variety of sources in a configurable manner.
   4. The option to inject custom code as a plugin when absolutely necessary.

2. Yes, clients come up with weird requests. It's usually worthwhile to suggest alternative solutions that will still solve the client's problem while still allowing your product to be robust and configurable for other clients. Sometimes you just have to push back. Other times you'll have to do what they say, but use wise architectural practices to minimize the impact this could have on other client code.
3. Minimize use of the session to track state. Each page should have enough information on it to track the current page's state. Information that needs to persist even if the user clicks "Back" and starts doing something else should be stored in a database. I have found it useful, however, to keep a sort of breadcrumb tree on the session, to track how users got to a specific place and where to take them back to when they finish. But the ID of the node they're actually on currently needs to be persisted on a page-by-page basis, and sent back with each request, so weird things don't happen when the user is browsing to different pages in different tabs.
4. Use incremental refactoring. You may end up re-writing the whole thing twice by the time you're done, or you may never really "finish" the refactoring. But in the meantime, everything will still work, and you'll have new features every so often. As a rule, rewriting the whole thing will take you several times as long as you think it will, so don't try to take the whole thing in a single bite.

这篇关于动态表单创建在asp.net c＃的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！