什么时候可以模糊数据和逻辑之间的抽象？
我的意思是通过 ID、代码或指定数据库中的类名来引用特定的数据库行。示例：
您有一个名为 SocialNetwork 的数据库表。这是一个查找表。应用程序不会对其进行写入或删除。它主要是为了数据库的完整性；假设整个 shebang 看起来像这样：
SocialNetwork table:
Id | Description
-----------------------------
1 | Facebook
2 | Twitter
SocialNetworkUserName table:
Id | SocialNetworkId | Name
---------------------------------------------------
1 | 2 | @seanssean
2 | 1 | SeanM
在您的代码中，需要为 Facebook 用户执行一些特殊的逻辑。我通常做的是在代码中创建一个枚举或一些类常量以便轻松引用它，例如：
if (socailNetwork.Id == SocialNetwork.FACEBOOK ) // SocialNetwork.FACEBOOK = 1
// special facebook-specific functionality here
这是一个硬编码的数据库 ID。这并不是一个巨大的犯罪，因为它只是引用一个查找表，但是数据和逻辑之间不再有明确的划分，这让我很困扰。
我能想到的另一个选择是在数据库中指定类或委托的名称，但这在我看来更糟糕，因为现在您不仅打破了数据和逻辑之间的划分，而且还把自己束缚在一个数据和逻辑之间。现在的语言。
我是不是无事生非？
I mean referring to specific database rows by their ID, from code, or specifying a class name in the database. Example:
You have a database table called SocialNetwork. It's a lookup table. The application doesn't write or or delete from it. It's mostly there for database integrity; let's say the whole shebang looks like this:
SocialNetwork table:
Id | Description
-----------------------------
1 | Facebook
2 | Twitter
SocialNetworkUserName table:
Id | SocialNetworkId | Name
---------------------------------------------------
1 | 2 | @seanssean
2 | 1 | SeanM
In your code, there's some special logic that needs to be carried out for Facebook users. What I usually do is make either an enum or some class constants in the code to easily refer to it, like:
if (socailNetwork.Id == SocialNetwork.FACEBOOK ) // SocialNetwork.FACEBOOK = 1
// special facebook-specific functionality here
That's a hard-coded database ID. It's not a huge crime since it's just referencing a lookup table, but there's no longer a clean division between data and logic, and it bothers me.
The other option I can think of would be to specify the name of a class or delegate in the database, but that's even worse IMO because now you've not only broken the division between data and logic, but you've tied yourself to one language now.
Am I making much ado about nothing?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我没有看到问题所在。
在某些时候你的代码需要做一些事情。 Facebook 是一个真正的社交网络，拥有自己真正的 API，您希望它在您的代码中执行 Facebook 特定的操作。除非您的任务很简单，否则将所有 Facebook 特定的内容放入数据库将意味着您的代码会很麻烦。 （例如，Twitter 中的“赞”相当于什么？）
如果 Facebook 条目不在您的数据库中，则不会执行 Facebook 特定的代码。你能做到这么多。
I don't see the problem.
At some point your code needs to do things. Facebook is a real social network, with its own real API, and you want it to do Facebook-specific things in your code. Unless your tasks are trivial, to put all of the Facebook-specific stuff in the database would mean a headache in your code. (What's the equivalent of "Like" in Twitter, for example?)
If the Facebook entry isn't in your database, then the Facebook-specific code won't be executed. You can do that much.
是的，但需要注意的是“这取决于情况”。虽然不太可能改变，但是。
存储类或委托的名称可能不好，但存储类或委托工厂使用的标记则不然，因为它是语言中立的 - 但您总是会遇到以下问题必须在某处维持连接。除非您有一个与该表相关联的特定于语言的内容表，否则我相信您会被枪杀。
IMO 这种情况对于工厂/等来说比较好，而不是在主线代码中保持不断的比较。模式、枚举查找等来实现特定于网络的类查找/行为。主线代码不必关心它是如何实现的，它现在就这样做——这部分才是真正值得关注的。
但需要注意的是，最终它可能永远都不重要。如果是我，我至少会解耦主线代码，因为这样的东西让我感到不安。
Yep, but with the caveat that "it depends." It's unlikely to change, but.
Storing the name of a class or delegate is probably bad, but storing a token used by a class or delegate factory isn't, because it's language-neutral--but you'll always have the problem of having to maintain the connection somewhere. Unless you have a table of language-specific things tied to that table, at which point I believe you'd be shot.
Rather than keep the constant comparison in mainline code, IMO this kind of situation is nice for a factory/etc. pattern, enum lookup, etc. to implement network-specific class lookup/behavior. The mainline code shouldn't have to care how it's implemented, which it does right now--that part is a genuine concern.
With the caveat that ultimately it may never matter. If it were me, I'd at least de-couple the mainline code, because stuff like that makes me twitchy.