标签: business-logic-layer

拥有没有以下BLL（业务逻辑层）的ASP.Net 2.0应用程序是否“可以接受” ？

1. SQL Server数据存储和存储过程
2. 数据链接层（强类型表适配器）连接到存储的Procs
3. 带有代码和ObjectDataSource的表示层ASPX页面，用于直接连接到DLL

即使业务逻辑在演示文稿的代码中完全有效，BLL还是总是可取的吗？不使用BLL有哪些潜在的缺点？

我有一个使用三层架构的ASP.net(C#)项目.我开始在我的DAL中使用Entity Framework,问题是Entity Framework生成的类在业务逻辑层中可以使用的程度是多少？

最好直接使用它们,还是应该创建自己的业务对象并从Entity Framework(db-> O/RM-> BOs)映射到它们？

我知道这是一个非常基本的问题.但我真的无法理解BLL中应该有什么. 让我举个例子.
让我们考虑一个Login.aspx网页,用于方便用户登录.
在这种情况下,Login.aspx将有两个文本框和一个登录按钮.(表示层).
数据访问层将具有检查用户名和密码是否正确的功能.

我不认为我在这个页面需要别的东西.那么我将在BLL中拥有什么？如果你想添加BLL中应该包含的一些功能,请添加.

我有一个应用程序,可以对成员进行复杂的计算.每个成员可以将多个美国州与其个人资料相关联.每个州对会员完成的每门课程都有不同的计算方法.

截至目前,我一直在数据库(SQL Server 2008)中执行计算,然后将数据发送回应用程序层,在那里他们可以看到他们的历史记录,然后为每个课程下载证书.

我有一个业务逻辑层,但不是很多.我知道这已被问了很多,但你认为我应该在哪里进行这些计算:业务层或数据库？我要来回走!!

我没有使用任何ORM.因此,我正在讨论"保存"方法是否实际上属于业务域实体,还是应该在某些服务中进行抽象,这些服务将通过业务域实体进行保存？

例如

class Employee
{
    string Name;
    DateTime Birth;

    GetAge()
    {

    }

    Save()
    {
    }           

}

要么

class Employee
{   
    string Name;
    DateTime Birth;

    GetAge()
    {

    }


}

SomePersistenceService
{
    Save(Employee emp)
        {
        }
}

目前，我正在开发一个利用多层体系结构的项目，如Application Architecture Guide 2.0中所述，它具有5个层（DAL，BLL，Facade，表示层和公共层）。
在这里，我们有一个业务逻辑层，它由业务组件和业务实体（它们是使用O / R映射器生成的实体）组成，通常我们需要在表示层中使用该实体来绑定数据并将其呈现给用户，因此我们会对这些实体进行气泡处理直到其他层的Presentation层。

现在的问题是：
这是正确的方法吗？（据我的定义，如果我们应该共享这些内容，则应将它们放置在“公共层”中，以便可以在所有层中使用它们）。我们不应该将这些实体移到公共层吗？还是我们应该定义诸如数据传输对象（DTO）之类的东西，然后将它们传递给各层（当然这似乎是多余的）。

任何澄清将不胜感激。

我有一个典型的Web应用程序,控制器调用业务方法.是否应使用静态方法或实例方法实现业务类中的方法.业务层类不维护任何状态信息.

一些其他信息+业务类不维护特定于州的信息.+在每个请求的基础上实例化这些对象会消耗大量内存,而不是使用静态方法

我想创建一个既可以在本地也可以在线工作的游戏.

我的第一个想法是创建一个接口,该接口将具有GUI为业务逻辑所需的所有方法,然后具有网络实现和本地实现.

这适用于请求 - 响应消息.但是,服务器发送的消息呢,我必须更新一些GUI组件(即JLabel)？

我的第一个解决方案是实现监听器,其中实现中的每个更改都将触发事件.GUI将适当地注册和更改它的组件.但是,在业务逻辑中调用触发事件看起来有点不对劲.

我是在正确的轨道吗？因为我想我不是.有什么建议？

谢谢.

注意:客户端是一个简单的Java Swing GUI.

我对BLL和DAL的关系有点困惑.BLL是否应通过依赖注入封装DAL？或者BLL是否只对域对象和DAL单独保存/更新？

例如,想象(在典型的MVC应用程序中)取消订单功能,要求您更新订单并更新库存.以下是我的行动的样子吗？

public ActionResult CancelOrder (Guid orderId) {
    Order order = orderRepository.Get(orderId);
    StockItem stockItem = stockRepository.Get(order.StockItemId);

    _orderService.CancelOrder(order, stockItem);
    orderRepository.Update(order);
    orderRepository.Update(stock);
    Return View();
}

或者它应该更像下面这样？

public ActionResult CancelOrder (Guid orderId) {
    _orderService.CancelOrder(orderId);
    Return View();
}

(within OrderService)
public void CancelOrder(Guid orderId) {
    Order order = orderRepository.Get(orderId);
    StockItem stockItem = stockRepository.Get(order.StockItemId);

    order.Cancelled = true;
    stockItem.AmountInStock = stockItem.AmountInStock + order.Amount;
    orderRepository.Update(order);
    orderRepository.Update(stock);
}

使用此选项,BLL将处理所有内容,包括数据访问.将注入存储库以避免紧密耦合.然后,任何实体检索将采用_orderService.GetOrder(orderId);相似的形式直接进入存储库.

请原谅示例的粗糙,因为我没有太多时间.我写的任何东西都是有意义的,还是我在荒野中？

我通常将数据集创建为DAL,并将BLL INSIDE创建为原始项目.

在我学习了Entity Framework之后,我知道业务逻辑层通常是在分离的项目(类库)中创建的.

但是,ASP.NET站点没有相应的教程.

出于这个原因,我特别在引用时创建BLL时很困惑.

1. 为了完成BLL类,我应该直接添加这样的引用吗？

然后使用USING语句访问实体:

但是,访问BLL的主项目中的表示层可能需要引用回BLL项目.我看到一些示例将整个BLL项目的DLL文件放在主项目中.

参考BLL和Main项目的正确方法是什么,或者只是参考上面的内容？

我可以学习任何好的教程吗？