如何划分一个有数百个字段的Entity？
我想要使用 Silverlight 4、业务应用程序模板、WCF RIA 服务和实体框架 4 设计 CRUD 业务应用程序的建议。该应用程序跟踪对材料样本执行的实验室测试结果。它取代了（难以维护的）现有 Web 应用程序。实验室测试结果存储在两个由数百个字段组成的“SampleData”表中。这些表具有一对一的关系。我使用实体框架的每类型继承表将两个表合并为一个表，我对此非常满意。注意：我决定不更改数据库设计以避免破坏现有应用程序，但是
我的困境是如何分解这张巨大的桌子。每条记录代表一个经过测试的材料样本。字段的逻辑分组是通过实验室测试进行的。我设想我的用户界面有多个选项卡或单独的页面 - 每个测试一个。此时的问题是，我吸收了所有字段，但只在分页 DataGrid 中显示了一些字段，并且存在明显的延迟。拥有多个“实验室测试”实体（每个实体代表一种测试类型）而不是一个巨大的实体可能会更好，这些实体是我的一个巨大的 TPT 继承表的子集。我该怎么做？基本 SampleData 表/实体包含标头字段以及几个子测试结果字段。第二个派生表/实体包含更多通过 SampleID 链接到基础的测试结果字段。如果拆分，我需要维护每个实验室测试实体的标头信息。
我愿意坚持使用一个巨大的表/实体（尽管性能略有下降）。尽管如此，我还是想知道使用这个实体创建 UI 的最佳方法。 DataForm 可以选项卡式吗？如果我制作一个包含实验室测试链接的仪表板，如何使标题信息与每个测试页面保持同步？
我知道这是一个广泛的问题。我希望获得有关良好设计路径的建议，这将使我能够在添加新的实验室测试时扩展应用程序（形成更大的实体）。我希望找到一条能够简化维护并利用 Microsoft 正在推广的 RAD 体验的途径。
提前致谢！
I'd like suggestions for the design of a CRUD business app using Silverlight 4, the Business Application Template, WCF RIA Services and the Entity Framework 4. The app tracks lab test results performed on material samples. It replaces a (difficult to maintain) existing web application. Lab tests results are stored in two "SampleData" tables made up of hundreds of fields. The tables have a one to one relationship. I combined the two tables into one using Entity Framework's Table Per Type Inheritance which I'm very happy with. Note: I've decided not to change the database design to avoid destroying the existing application, but it was considered.
My dilemma is how to break up this huge table. Each record represents a material sample that is tested. The logical grouping of fields is by lab test. I envision my UI having multiple tabs or separate pages - one for each test. The problem at this point is that I'm sucking in ALL the fields yet only displaying a few in a paged DataGrid and there is a noticeable delay. Instead of one giant entity it might be nice to have several "Lab Test" entities (each representing a type of test) that are sub-sets of my one giant TPT Inheritance table. How would I do this? The base SampleData table/entity contains header fields plus several child test results fields. The second derived table/entity contains more test result fields linked to the base by SampleID. If split up I'd need to maintain the header info with each Lab Test entity.
I'm willing to stick with one giant table/entity (despite a slight performance penalty). Still, I'm wondering the best way to create my UI with this one entity. Can a DataForm be tabbed? If I make a dashboard with links to lab tests how do I keep header info in sync with each test page?
I know this is a broad question. I'm hoping to get suggestions on a good design path that will allow me to grow the app as new lab tests are added (making an even bigger entity). I'd hope to find a path that simplifies maintenance and takes advantage of the RAD experience Microsoft is promoting.
Thanks in advance!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我浏览了讨论数据库设计的帖子，并且必须说，根据您所说的以及您已经有用户要求进行更多测试（重复值）的事实，我希望您重新考虑数据库重新设计。您可以创建一个平面视图来模拟现有的平面样本数据表，并使用它来最大限度地减少现有应用程序的损坏。
但你已经做出了决定，那么扭转局势如何？无需修复数据库，而是将代码添加到域服务中，将数据从平面布局中转换出来，并忽略所有空值。
一个想法是编写一个视图来取消数据扁平化并忽略空的无测试情况。该查询会引起人们的注意（我可能会因此而受到批评），因为它看起来很糟糕，但实际上 DBMS 在优化和执行查询方面做得很好（无论如何在 Oracle 中）。我已经取得了很好的结果，使视图类似于::
create viewprogrammer_exp_unflat as (
从programmer_exp_flat中选择programmer_id, 'C#', csharp_yrs，其中csharp_yrs不为空
联盟
从programmer_exp_flat中选择programmer_id, 'Java', java_yrs，其中java_yrs不为空
联盟
从programmer_exp_flat中选择programmer_id, 'Cobol', cobol_yrs，其中cobol_yrs不为空
。
重复xx次）从双
它是倒退和丑陋的，无论你怎么看它，但它将你的结果集减少到最低限度，并且不需要将事情分成类别。新的测试值需要修改视图，并且根据 UI 灵活性和业务规则，可能不需要任何更改。
它使 UI 上的编码变得更加困难，因为首先要进行正确的数据库设计，但您的查询结果会减少到仅包含已完成的测试。如果您的用户很灵活，则可以将 UI 设计为将测试结果显示为列表，从而使显示变得轻而易举。您当前的设计几乎迫使您在每个新测试中修改 UI 和数据库。
这些类型的挑战让开发人员变得如此有趣 - 以及为什么所有可以在五分钟内构建的营销花招示例 CRUD 应用程序在现实世界中毫无价值。
I scanned the post discussing the database design and must say that based on what you said and the fact that you've already got users asking for more tests (repeating values) that I wish you'd reconsider the db redesign. You can create a flat view to simulate the existing flat samples-data table and use that to minimize breakage in the existing application.
But you've already made that decision, so how about reversing the situation? Instead of fixing the database, add code to the domain service that transforms the data from it's flat layout, leaving out all the null values.
One idea is to write a view that un-flattens the data and leaving out the null no-test situations. The query will raise eyebrows (I'll probably get flamed for this) because it looks nasty but in reality the DBMS does a fine job optimizing and performing the query (in Oracle anyway). I've had great results making a view something like::
create view programmer_exp_unflat as (
select programmer_id, 'C#', csharp_yrs from programmer_exp_flat where csharp_yrs is not null
union
select programmer_id, 'Java', java_yrs from programmer_exp_flat where java_yrs is not null
union
select programmer_id, 'Cobol', cobol_yrs from programmer_exp_flat where cobol_yrs is not null
.
repeat xx times) from dual
It's backwards and ugly no matter how you look at it but it reduces your result set to a bare minimum and no need to break things into categories. New test values require modification of the view, and depending on UI flexibility and business rules, might not require any changes.
It makes coding at the UI more difficult, as it would have been with the right database design in the first place, but your query result is reduced to only the tests that had been completed. If your users are flexible the UI could be designed to show the test results as a list making display a piece of cake. Your current design pretty much forces you to modify the UI and database with each and every new test.
These are the type challenges that make being a developer so much fun -- and why all the marketing gimmick sample CRUD applications that can be built in five minutes are worthless in the real world.
我正在回答（并接受）我自己的问题，以提高我的堆栈溢出接受率，但我的“答案”是我还没有找到答案。因为我必须继续该项目，所以我继续使用一个巨大的实体。由于 Silverlight 存在各种问题（例如固有的异步数据访问），我还放弃了 Silverlight，并将该项目转变为 WPF 应用程序。
I'm answering (and accepting) my own question to increase my stack overflow accept rate, but my "answer" is that I have found no answer yet. Because I've had to move on with the project I continue to use one giant entity. I've also moved away from Silverlight and turned the project into a WPF app due to various struggles with Silverlight such as inherent asynchronous data access.