MVC、实体框架、业务逻辑

发布于 09-24 08:25 字数 481 浏览 10 评论 0原文

尽管我相信我已经很好地掌握了 MVC(来自 Rails),但我正在学习 ASP.NET MVC 的“MS 方式”。

另外,我也在学习实体框架。

我在模型文件夹中创建了一个名为 User 的实体。使用 LINQ to EF 我可以检索记录,一切都很好。

现在,我想放入一些业务(或者我所说的域)逻辑。但在我看来,EF 更多的是 DAL。因此,我创建了一个名为“Domain”的文件夹,并在其中为一些业务规则创建了一个类。

其中之一是对密码进行加密。

因此,我可以在控制器中使用以下内容:

string password = Domain.User.EncryptPassword(string salt, string password);

此外,这意味着域逻辑在需要持久保存到数据库时可以访问 EF 用户。

这个逻辑合理吗?

任何建议表示赞赏。

谢谢!

Although I believe I have a good grasp on MVC (from Rails), I'm learning the "MS Way" with ASP.NET MVC.

Also, I am learning Entity Framework as well.

I've created an Entity called User in my Models folder. Using LINQ to EF I can retrieve records and all is good.

Now, I want to put some business (or what I call, domain) logic in. But in my mind, EF is more of the DAL. So I created a folder called "Domain" and in there, I created a class for some business rules.

One of them is to encrypt passwords.

So I can use the following in my controllers:

string password = Domain.User.EncryptPassword(string salt, string password);

Also, that means the domain logic can access the EF User when it needs to persist to the DB.

Is this logic sound?

Any recommendations appreciated.

Thanks!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

请持续率性2024-10-01 08:25:27

我唯一要问的是:“为什么一个用户,一个人,知道如何加密或散列密码?”

加密密码将是应用程序层的一部分。这几乎是反DDD的。

The only thing I would ask is: "Why would a user, a person, know how to encrypt or hash a password?"

Encrypting a password would be part of an Application layer. This is almost anti-DDD.

夏有森光若流苏2024-10-01 08:25:27

这有点取决于项目,但通常我们:

  • 不要在 EF 模型中放置任何代码,所有模型都存储在单独的项目中,
  • 在 MVC 代码和 EF 之间放置一个业务层。在 EF 的早期版本中,这将用于将 EF 对象映射到域对象,但对于 POCO,不再需要这。任何缓存都将在这一层中完成。
  • 使用帮助程序或实用程序类进行加密

It depends a bit on the project, but generally we:

  • do not put any code in the EF models, all models are stored in a seperate project
  • place a business layer between the MVC code and EF. In previous versions of EF this would be used to map EF objects to domain objects, but with POCO this is no longer needed. Any caching would be done in this layer.
  • use a helper or utility class for encryption
昨迟人2024-10-01 08:25:27

我认为您正在寻找的是 POCO(普通旧 CLR 对象)。一方面,您拥有 EF 实体。另一方面,您拥有域或业务实体...然后您可以映射它们...您的 DAL 层必须返回 POCO 实体而不是 EF 实体...至少在 3 层应用程序中是这样的。我想这与 MVC 应用程序中的方法相同......

我是对的吗?

I think what you are looking for is POCO (Plain Old CLR Objects). In one hand you have your EF entities. In the other hand you have your Domain or Business Entities... and then you can map them... your DAL Layer must return POCO entities and not EF entities.. at least that's how is made in a 3-tier application. I suppose it's the same approach in a MVC application...

Am I right?

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文