我正在使用 MVC3 和实体框架开发应用程序。它是一种三层方法，表示层托管在 Web 服务器中，业务层和数据访问层托管在应用程序服务器中。我们没有将对象上下文暴露给表示层或业务层。对象上下文仅包装在数据访问层中，并将数据访问和数据持久性作为数据访问层方法的功能公开（即数据访问逻辑仅在数据访问层中分离和实现）。业务层调用数据访问层的方法并将数据返回给表示层。
我担心的是大多数业务层方法只是为了访问数据，它只是将调用转发到数据访问层而没有任何操作。所以我们在两层重复代码。我们有没有其他更好的方法来避免这种重复。
以分层方法在业务层中实现数据访问逻辑是否是一种好习惯？
有人可以为具有 3 层架构的分层应用程序提出一个好的实现方法吗？
如前所述，没有“正确”的设置方式。这些年来，我发现了一些可以帮助我决定采用哪种方法的东西。
两层
如果您的商店存储过程繁重，有很多数据库程序员，并且倾向于将业务逻辑放在数据库中，那么请使用两层方法。在这种情况下你会发现你的业务层一般只是调用数据层。此外，如果您的代码库和页面往往很小并且您从不重复功能，那么请使用两层方法。你会节省很多时间。
三层
如果您的商店喜欢在代码中包含大量业务逻辑并且该逻辑在各处重复，那么请使用三层。即使您注意到很多业务层只是调用数据层，随着时间的推移，当您添加功能时，您会发现向业务层添加代码要容易得多。此外，如果您有一个庞大的代码库，其中包含大量重复逻辑的页面，那么我肯定会采用这种方法。
我在工作中的企业级应用程序中发现了两者的混合。有问题的区域是使用动态 sql (gag) 并且业务逻辑一遍又一遍地重复的区域。我发现当我重构时，我将这段代码放入一个 3 层架构中，并在未来为自己节省了大量时间，因为我可以重用它。
如果您发现自己的业务层所做的只是将调用委托给数据访问层，那么这强烈表明该业务层对于您的应用程序可能不是必需的，因为它不会带来额外的价值。您可以摆脱它并让控制器直接与数据访问层对话（当然是通过抽象）——这就是大多数教程在 EF 数据上下文中所展示的内容。
在主要由 CRUD 操作组成的简单应用程序中，可能不需要业务层。随着您的应用程序变得越来越复杂，您可能会决定稍后再引入它，但不要从一开始就进行太多抽象，特别是如果这些抽象不会给您带来任何额外的价值。
我认为复制代码以进行逻辑分离不一定是坏事。当这将得到回报时，时间将会到来。假设您将用 Oracle 替换 SQL 服务器。或者微软会提出 Linq 2.0，一些实现会改变。您会感谢自己将它分开，而那些直接从业务层调用数据库的人将不得不在两个地方进行修改 - DAL 和 BLL。物有所值。但同样，没有正确的答案，取决于实用性、可用性、便利性，最重要的是让它符合其目的。
希望这是有帮助的。