设计问题asp.net c＃

Question

我正在一个网站上工作，我有许多查找值，如城市，州，国家 汽车品牌，型号等等。这些价值观有两个领域 ID和说明。现在我有一个问题，我应该把它们放在一张桌子上并保留一些 TypeId类型的区域，它们区分它们或者它们应该保留在不同的表中。

另外我的Dataprovider类怎么样，目前我想要有一个类 可以提供所有数据。但是，我觉得这堂课会有很多方法。

欢迎提出建议。

此致 成员Parminder

Answer 1

相信我，时间会在有人说，“嘿，我们可以为城市增加纬度/经度”，你会自己踢，因为这些属性对于汽车品牌和模型毫无意义。

物理上分离不相关的，不相交的实体，你真的不会出错。所以我建议使用不同的表格。

Answer 2

始终将查找放在自己的表中，以便您可以在相关表上获得有意义的外键以实现关系完整性（即Customer表中的CountryID引用Country表中的CountryID）。

您的查找架构也可能与每个实体的标准ID /描述不同，因此“一刀切”并非最佳启动方式。

此外，每次查找都有一个存储库/数据提供者，不要将它们全部混合到一个大的类中，因为它会变得笨拙和不诚实。

Answer 3

我已经看到它完成了两种方式，但就可发现性而言，我更喜欢为每个数据分别设置一个表。维护多个表并不困难，当您决定需要在其中一个项目中添加一列或两列时，它会使事情变得更加容易。

Answer 4

我希望您将它们放在单独的表中，以便于区分。

至于dataprovider类，我建议你使用ORM，而不是决定如何编写dataprovider类。

Answer 5

真的取决于，如果你在销售产品，我会说是的，将它们保存在一个表中，并使用某种TypeID来区分产品的类型。例如，如果您销售的商品，您的TypeID可能是汽车，教育等。

但是，如果您正在处理为特定目的服务的不同实体，并且每个实体之间并不真正相互关联，那么分离是好的。我们需要更多信息来帮助您:)。

Dataprovider可以是一个类，即您的数据访问层，并且您可能有很多方法并不重要;这很正常。

Answer 6

城市，州，国家似乎是不同的实体。

因此最好将这些细节保留为单独的主表。

如果有任何关系，则使用外键将它们联系起来。

如果有任何更改或更新，将减少未来的开销 如果这些都在一个表格中，也可以减少对DB的负担。

编写一个单独的DBProvider来执行SP，adhoc查询

并创建单独的BusinessModel，表示每个表 与DBProvider和客户端的前端进行交互。

这应该是完美的设计策略。

Answer 7

这取决于这些实体的方案和域。让我们说在设计时如果你不知道你将拥有的实体类型，那么TypeId方法更好，这样当添加新类型时，你不必为它创建另一个实体。但是，如果在设计时你确定实体域（你将拥有的实体是什么），那么将它们保存在单独的表中，以便更有效地优化搜索。

但是，请考虑如果实体的属性需要更新（添加，编辑，删除等），如果将它们保存在一个表中，更新可能会影响所有其他属性。如果您以后需要在您的桌子上添加关系，那该怎么办？所有不相关的实体也可以继承这种关系。

Answer 8

关于你的Dataprovider类 - 如果它太大，这可以被认为是code smell，这通常被认为是一种不好的做法。决定有多大是有点主观的。

来自文章：

  

大班：一个已经成长的班级   太大了，请参阅God object。

Answer 9

如果您认为随着时间的推移，不同类型的数据将获得不同的属性，那么将它们分别放在自己的表中。但是，如果您认为它们总是只是 ID 和描述，那么为了简单起见，请将它们全部放在同一个表格中，其中包含 TypeId

我同意其他建议使用第三方数据访问或OR / M组件，如LINQ-to-SQL，NHibernate，SubSonic，LLBLGen Pro等。