没有真正的 OOP 或对象的动态表单?
我正在对一个项目进行大型重构,并且我问了这个问题 确认/理解我应该进入的方向,我想我得到了我想要的答案,这不是扔掉多年的代码。因此,现在开始重构代码的挑战。我一直在阅读 Martine Fowler 和 Martin Feathers 的书,他们有很多见解,但我正在寻求有关我希望应用程序实现的最终目标的建议。
因此,稍微重申一下该应用程序,它是一个动态表单系统,在字段之间具有大量验证逻辑和数据逻辑。插入的主要记录是页面上的一组表单字段。它的另一部分是你可以为一个人做的“行动”。这些“操作”可能因客户而异,并且有数百个“操作”。还有传言说,我们可以以某种方式制造一个最终可以应用于其他类似领域的引擎,其中“人”可以是其他东西(例如学生或员工)。所以我想构建一些非常解耦的东西。我们有一个代码库,但针对不同的客户有不同的数据库。页面上的表单字段集是动态的,但数据库不是动态的 - 它通过存储过程转换为特定的数据库表。因此,通用字段集被发送到存储过程,然后存储过程决定如何处理这些字段(找出它需要转到哪个表)。这些表实际上是相当静态的,这意味着它们并不是真正动态的,并且有一定的结构。
我特别纠结的是如何设置一个好的方法来执行动态表单控制页面。似乎大部分逻辑都在 UI/aspx.cs 页面上的代码中,因为它将控件加载到网页上。有什么办法可以做到这一点,所以它是以精简的方式完成的,所以 aspx.cs 页面不是 5000 行长?我有一个“FORM”对象,其属性之一是其“FIELDS”。所以这个对象被加载到业务层和数据层中,但现在在前端,它必须循环遍历FIELDS并将控件输出到页面上。另外,以某种方式能够控制放置也会很有用 - 不知道如何将其放入这个模型中......
另外,从另一个角度来看 - 我如何“真正”将其放入面向对象的模型中-结构?因为从技术上讲,他们可以创造任何形式。这些表单字段可以代表任何对象。因此,例如,今天他们可以创建一组代表“人”的表单字段 - 明天他们可以创建一组代表“家具”的表单字段。我怎样才能将其转化为一个人或一个家具物体(或者我什至应该尝试这样做?)。而且我实际上无法控制表单字段,因为它们可以创建任何内容......
任何思考过程都会非常有帮助 - 谢谢!
I am tacking a large refactor of a project, and I had asked this question to confirm/understand the direction I should go in and I think I got the answer that I wanted, which is not to throw away years worth of code. So, now begins the challenge of refactoring the code. I've been reading Martine Fowler and Martin Feathers' books, and they have a lot of insight, but I am looking for advice on the ultimate goal of where I want the application to be.
So to reiterate the application a little bit, its a dynamic forms system, with lots of validation logic and data logic between the fields. The main record that gets inserted is the set of form fields that is on the page. Another part of it is 'Actions' that you can do for a person. These 'Actions' can differ client by client, and there are hundreds of 'Actions'. There is also talk that we can somehow make an engine that can eventually take on other similar areas, where a 'person' can be something else (such as student, or employee). So I want to build something very de-coupled. We have one codebase, but different DBs for different clients. The set of form fields on the page are dynamic, but the DB is not - it is translated into the specific DB table via stored procs. So, the generic set of fields are sent to the stored proc and the stored proc then decides what to do with the fields (figure out which table it needs to go to). These tables in fact are pretty static, meaning that they are not really dynamic, and there is a certain structure to it.
What I'm struggling specifically is how to setup a good way to do the dynamic form control page. It seems majority of the logic will be in code on the UI/aspx.cs page, because its loading controls onto the webpage. Is there some way I can do this, so it is done in a streamlined fashion, so the aspx.cs page isn't 5000 lines long? I have a 'FORM' object, and one of the properties is its' 'FIELDS'. So this object is loaded up in the business layer and the Data layer, but now on the fron end, it has to loop through the FIELDS and output the controls onto the page. Also, someway to be able to control the placement would be useful, too - not sure how do get that into this model....
Also, from another point of view - how can I 'really' get this into an object-oriented-structure? Because technically, they can create forms of anything. And those form fields can represent any object. So, for example, today they can create a set of form fields, that represent a 'person' - tomorrow they can create a set of form fields that represent a 'furniture'. How can I possibly translate this to to a person or a furniture object (or should I even be trying to?). And I don't really have controls over the form fields, because they can create whatever....
Any thought process would be really helpful - thanks!
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
如果我理解正确,您可能不应该尝试将这些字段转换为特定对象,因为您的应用程序的性质是如此动态。如果存储过程能够确定哪些字段组合属于哪些表,那就太好了。
如果您可以更改数据库模式,我建议您想出一些更加动态的东西。我不会为每种类型的动态对象创建一个表,而是创建以下架构:
如果无法更改数据库架构,您仍然可以使用存储过程和固定表将以下内容应用于旧系统:
然后当您从数据库中读取特定对象时,您可以循环遍历每个属性并获取表单类型,然后简单地将适当的通用表单类型添加到页面中:
当然,我放入了一个 PageForm 对象,以及 CheckboxFormField 和EmailFormField 对象。 PageForm 对象可以只是一个占位符,CheckboxFormField 和 EmailFormField 可以是 UserControls 或 ServerControls。
我不建议尝试控制布局。只需垂直地一一列出每个字段即可。无论如何,这变得越来越流行,即使使用静态表单,其布局也可以完全控制。例如,大多数注册表单都遵循此约定。
我希望这有帮助。如果我错误地理解了您的问题,或者您需要进一步的解释,请告诉我。
If I understand you correctly, you probably shouldn't try to convert these fields to specific objects since the nature of your application is so dynamic. If the stored procedures are capable of figuring out which combination of fields belongs to which tables, then great.
If you can change the DB schema, I would suggest coming up with something much more dynamic. Rather than have a single table for each type of dynamic object, I would create the following schema:
If you can't change the database schema, you can still apply the following to the old system using the stored procedures and fixed tables:
Then when you read in a specific object from the database, you can loop through each of the properties and get the form type and simple add the appropriate generic form type to the page:
Of course, I threw in a PageForm object, as well as CheckboxFormField and EmailFormField objects. The PageForm object could simply be a placeholder, and the CheckboxFormField and EmailFormField could be UserControls or ServerControls.
I would not recommend trying to control placement. Just list off each field one by one vertically. This is becoming more and more popular anyway, even with static forms who's layout can be controlled completely. Most signup forms, for example, follow this convention.
I hope that helps. If I understood your question wrong, or if you'd like further explanations, let me know.
不确定我理解这个问题。但是有两个工具箱适合编写通用代码。它是泛型,也是反射——通常是组合。
我认为我并不真正理解您想要做什么,但是使用反射来识别对象的所有属性的方法可能如下所示:
您还可以查看我的博客上的一个条目,其中我讨论了在对象与反射相结合。它实际上是在讨论如何利用它来编写通用 UI。不完全是你想要的,但至少可以使用相同的原则。
http://codepatrol.wordpress.com/2011/08/19/129/
这意味着您可以创建自己的自定义属性,或者使用 .NET 框架中已经存在的属性来描述您的类型。可以使用指定验证规则、字段标签、甚至字段放置的属性。
然后,您将使用我的博客中描述的方法来识别这些属性并采取适当的操作 - 例如,将它们放在正确的行中,给出正确的标签,等等。我不会提出如何解决这些问题,但至少反射是一个伟大而简单的工具,可以获取有关未知类型的描述性信息。
Not sure I understand the question. But there's two toolboxes suitable for writing generic code. It's generics, and it's reflection - typically in combination.
I don't think I really understand what you're trying to do, but a method using relfection to identify all the properties of an object might look like this:
You can also check out an entry on my blog where I discuss using attributes on objects in conjunction with reflection. It's actually discussing how this can be utilized to write generic UI. Not exactly what you want, but at least the same principles could be used.
http://codepatrol.wordpress.com/2011/08/19/129/
This means that you could create your own custom attributes, or use those that already exists within the .NET framework already, to describe your types. Attributes to specify rules for validation, field label, even field placement could be used.
Then you'd use the method described in my blog to identify these attributes and take the apropriate action - e.g. placing them in the proper row, giving the correct label, and so forth. I won't propose how to solve these things, but at least reflection is a great and simple tool to get descriptive information about an unknown type.
我发现 xml 对于同样的情况非常有用。您可以在代码中构建对象图来轻松表示表单。该对象图可以再次轻松地从数据库加载/保存。
您可以将对象图转换为 xml &使用xslt生成html用于显示。您现在还可以为不同的客户端/版本/等自定义此转换。我还将 xml 存储在数据库中以提高性能和性能。给我一个发布功能。
您需要一些特定的代码来处理传入的数据,因为您将访问原始请求帖子。您需要根据您认为显示的内容来验证传入的数据。这可以防止人们欺骗/干扰您的表单。
我希望一切都有意义。
I found xml invaluable for this same situation. You can build an object graph in your code to represent the form easily enough. This object graph can again be loaded/saved from a db easily.
You can turn your object graph into xml & use xslt to generate the html for display. You now also have the benefit of customising this transform for differnetn clients/versions/etc. I also store the xml in the database for performance & to give me a publish function.
You need some specific code to deal with the incoming data, as you're going to be accessing the raw request post. You need to validate the incoming data against what you think you was shown. That stops people spoofing/meddling with your forms.
I hope that all makes sense.