如何在企业级应用程序中隐藏web项目的业务逻辑数据

我相信您对设计和关注点分离与类上的访问修饰符感到有点困惑。

要回顾一下并获得一个高层次的概述，首先看看典型的应用程序结构。

• 数据层—在最低级别，这是与数据库的1:1表示。这是您的数据被映射出来并正确规范化的地方，等等。
• 业务数据层—从数据层往上一步是业务层(特别是数据组件)。这些数据组件更好地代表了事物在"现实世界"中的工作方式，因为它们更好地模拟了实际发生的事情。
• 业务逻辑层—通常与上面的层配对，这一层封装了业务数据如何协同工作的逻辑。
• 表示层 -显示上述所有"东西"。请注意，这一层可能也有它自己的数据集，因为您显示业务对象的方式可能不是1:1的映射，因此可能必须从业务数据转换为用户实际如何查看该数据。

考虑到这一点，你提到你正在使用实体框架。实体框架是一个ORM，它将对象映射到不兼容的关系类型，创建某种"对象中的数据库"(或者像维基百科所说的"虚拟对象数据库")。这里要记住的一点是，EF就是在系统中管理数据对象的方式。它在很多方面使生活更容易，但它不是实际的数据。事实上，类是"公共的"是EntityFramework的要求，是的，但这并不意味着你需要允许访问或使用这些数据对象在你的项目的其他部分(虽然，有一个警告，我将在一段时间内得到)。

所以，现在，你可以创建一个应用程序，看起来像这样:

• 数据对象(使用EF帮助管理/使用它们)
• 业务层(将数据层转换为业务对象，提供业务逻辑)
视图层(也可能是一个网站)——利用业务层以一致和内聚的方式向用户显示信息。

我之前的警告-请注意下一层确实需要知道关于它下面的层。如果你从逻辑上考虑这个问题，如果你没有数据作为基础，你将如何创建业务层?但是，视图层不应该直接接触数据对象，业务逻辑(通常)不应该使用数据对象来做出业务决策。在图层之间移动有一个转换步骤。

如果这一切都清楚了，那么，回到你的问题。划分多少或不划分多少层完全取决于你作为设计师。我曾见过数据层与业务逻辑直接位于同一个项目中——特别是在没有真正的业务逻辑的情况下。见鬼，我见过一个非常简单的应用程序把所有东西都放在一个WebApp项目中。你必须考虑你的项目目前需要什么，如果你以某种方式设计东西，好处和坏处是什么。

一些值得考虑的事情:

• 如果你分开层，它变得更容易改变系统。(例如，如果添加了一些新的业务逻辑，你不需要改变你的数据层来支持它——你可以在一个地方改变它)
• 你拥有的层次越多，你就有越多的"杂耍"。通常，新手会看到自己在对象之间来回进行大量的转换和手动代码。看看像AutoMapper这样的工具来帮助自动化这一点。
• 如果你只是在学习技术，不要花大量的时间过度设计这个。你的进度会变慢，最终你可能会感到沮丧。
• 如果你正在开发一个大型的企业应用程序(例如，一个团队在每个层上工作)，或者它可能会有很多变化，那么将其分开可以真正帮助保持代码模块化，并允许每个团队在只需要知道另一个团队提供的接口的情况下工作。使生活更美好，因为它减少了协调。

关于这种类型的设计还有很多其他的文章。我建议你去谷歌上看看更多。希望这能澄清一些事情!