多用户金融客户经理应用程序设计推荐

Question

喜欢这个网站——在我的整个学习过程中，它提供了非常丰富的信息。刚刚完成了四分之一的 C# 介绍，其中一个项目是设计一个财务“账户管理器”应用程序，该应用程序保持余额并在进行提款和存款时更新它。该项目相当简单，我没有任何问题。不幸的是，我的下一个季度不包括任何编程课程 :(，所以我正在利用时间通过增强我的客户经理应用程序来扩展我的知识。

我想做的第一件事是启用多个用户。到目前为止，我已经包含了一个 CreateNewUser 类，该类禁止重复的用户名，检查新密码的特定格式要求，加盐和散列，并将其保存到带有用户名（电子邮件地址）和自动递增的“帐户”表中用户身份。很简单。

所以现在我陷入了困境：不确定最佳做法是什么。我不认为用户应该使用与其他用户相同的表，所以我认为每个用户都应该有自己的表。我是“过于偏执”，还是我的想法符合常见的编程安全实践？事实是，可能没有人会使用这个应用程序，但我正在努力学习我长大后可以在现实世界中应用什么。

使用同一个表只需要加载具有匹配用户ID 的查询的DataSet，所以这没什么大不了的。如果我应该使用单独的表，那么我需要在创建新用户时动态创建一个新表，并且我将使用用户 id 命名表，这将模拟现实世界中的帐号，我我假设。

无论如何，我找不到涵盖此问题的其他问题，所以我想我会问你的想法。

谢谢，

死神

Answer 1

这样想。如果您要保留这些表格的物理示例，例如，使用笔记本。您是想要很多小笔记本还是一个大笔记本也可以参考？

只要您的代码被编写为只提取正确的数据（在这种情况下，匹配用户 ID），安全方面就没有什么大不了的，因为您的所有代码都将处理对数据的访问权限。而且您的数据库和代码也设置了正确的权限。

Answer 2

到目前为止，我已经包含了一个禁止重复的 CreateNewUser 类 用户名，检查新密码的特定格式要求， 对其进行加盐和哈希处理，并将其保存到“帐户”表中 用户名（电子邮件地址）和自动递增的用户 ID。简单的 够了。

已经很糟糕了。它应该是一个用户表 - 处理财务信息的应用程序中的帐户具有非常特定的财务含义，您可能希望每个用户拥有多个帐户和/或用户共享一个帐户。

此外，除非您编写 Powershell CmdLets（其中每个命令一个类是模式），否则 CreateNewUser 类与出去烧车一样糟糕。用户是一个类，某种存储库是可以的，但如果有的话，CREATE NEW 就是类上的一个 FUNCTION。它绝对不是一个完整的类——如果你把类中的每一个方法都转过来，你就完全搞砸了面向对象的概念。

我认为用户不应该和其他用户使用同一张表，

又是一个完全的初学者错误。为什么不？输入适当的引用帐户和/或用户的字段，就可以了。

那么我需要在创建新用户时动态创建一个新表，

你有没有想过你在这里做什么？维护明智的每次更改都意味着编写一个程序来找出存在哪些用户表，然后修改它们。窗外的工具支持。我曾经看过一个这样写的应用程序——发票管理。 PER INVOICE 有一个发票明细表（每个发票有一个发票表，由发票号编码），因为程序员从不了解数据库是什么。

我是“过于偏执”，还是我的想法符合常见的编程安全实践？

他们的观点是“你被解雇了，学习数据库是如何工作的”。

使用同一张表只需要加载带有匹配用户ID的查询的DataSet

;) 所以 DataSet 还在吗？遵循微软过去 30 年来最糟糕的做法，您是否有理由进行考古编程 - 而不是使用微软自一段时间以来已经提供的 ORM（Linq2SQL，实体框架），这将使您的应用程序很多 - 啊 -更多 - 啊 - 面向对象？

我可以建议读一本像样的书吗？查找 Scott Ambler 的“构建有效的对象应用程序”？不，它不是为 C# 编写的 - 有趣的是，良好架构的概念 99% 与语言无关。