I agree with @MikeC. Separate the BLL in namespaces, for each segment. Also, separate the DAL too, like this:
MyCompany.HumanResources.DAL
MyCompany.Insurance.DAL
Another thing to do, is separate the dll's. This way, you dont need to make DAL public. It will be a Business Layer (like WCF or Web-service), responsible of BLL and DAL, for each system, making the support and maintenance more easy. I dont know if its the most affordable approach for your company right now (in terms of complexity), but its a better approach for design purposes.
Times before, the applications developed here in the company, used component architeture - sharing the components trough applications -. We realized that, it wasnt the best design and today, many systems (in production enviroment) use that design approach.
Furthermore: If you want more complexity, you could also generate a Generic dbHelper component, responsible to maintain the data access, including operations that controls the connections, commands and transactions. This way, preventing the rewrite of code. That assembly could makes use of Enterprise Library or others components. An operation example could be:
我捍卫使用 IoC 提供者，而不是直接使用业务管理器类（想想可能会导致噩梦的引用）。该解决方案解决了dll的隔离及其优化消耗的问题。
I suggest you to separate your business logic into different dll's in accordance to their pertence (in accordance with previous post), these classes will implement specific interface while this interface will be declared on you business login consumer. Then I suggest you to implement the containers (see Inversion of Control theory) to resolve dll implementation, this will allow you to separate business logic implementation from consumption and you will be able to replace some implementation by another, without difficulty.
I defend the use of provider with IoC and not the consumption of business manager classes directly (think about references which can result in nightmare). This solution resolves the problem of dll's isolation and their optimized consumption.
就数据访问而言，您可以在基本 BLL 中拥有通用数据访问例程。您的特定 BLL 可以有自己的专用数据查询，这些数据查询会汇集到基础 BLL，而基础 BLL 又使用通用 DAL 并将结果返回到链上。
It sounds like you have common business logic, that applies the your organization in general, and more specific logic per section or department. You could set up your code in a way so that each dept. only depends on their specific logic, which behind the scenes uses any generic functionality in the "base" logic. To that end, you could set up the following projects:
Business.BLL
Business.Finance.BLL
Business.IT.BLL
(etc, ad infinitum, and so on...)
Note that each of these can be a separate project, which compiles to its own assembly. A department would only need to use their own assembly.
As far as data access goes, you can have generic data access routines in your base BLL. Your specific BLLs can have their own specialized data queries that are funnelled to the base BLL, which in turn uses the generic DAL and returns results back up the chain.
发布评论
评论（4）
您应该为每个业务“部分”拥有不同的 BLL 和 DAL...例如：
You should have a distinct BLL and DAL for each "segment" of business... for example:
我同意@MikeC。对于每个段，在命名空间中分隔 BLL。另外，也分离 DAL，如下所示：
另一件要做的事情是分离 dll。这样，您就不需要公开 DAL。它将是一个业务层（如WCF或Web服务），负责每个系统的BLL和DAL，使支持和维护更加容易。我不知道这是否是您公司目前最实惠的方法（就复杂性而言），但对于设计目的来说，这是一种更好的方法。
以前，公司开发的应用程序使用组件架构 - 通过应用程序共享组件 -。我们意识到，这不是最好的设计，今天，许多系统（在生产环境中）都使用这种设计方法。
此外：如果您想要更复杂，您还可以生成一个 Generic dbHelper 组件，负责维护数据访问，包括控制连接、命令和事务的操作。这样，就可以防止代码被重写。该程序集可以使用企业库或其他组件。一个操作示例可以是：
您可以将其虚拟化，实现一个 SqlCommand CreateCommand 等等。
记住：我公开的 Generic dbHelper 想法只是一个想法！
I agree with @MikeC. Separate the BLL in namespaces, for each segment. Also, separate the DAL too, like this:
Another thing to do, is separate the dll's. This way, you dont need to make DAL public. It will be a Business Layer (like WCF or Web-service), responsible of BLL and DAL, for each system, making the support and maintenance more easy. I dont know if its the most affordable approach for your company right now (in terms of complexity), but its a better approach for design purposes.
Times before, the applications developed here in the company, used component architeture - sharing the components trough applications -. We realized that, it wasnt the best design and today, many systems (in production enviroment) use that design approach.
Furthermore: If you want more complexity, you could also generate a Generic dbHelper component, responsible to maintain the data access, including operations that controls the connections, commands and transactions. This way, preventing the rewrite of code. That assembly could makes use of Enterprise Library or others components. An operation example could be:
You can make it virtual, implementing a SqlCommand CreateCommand and so on.
Remembering: the Generic dbHelper idea I exposed, is just an idea!
我建议您根据其相关性将业务逻辑分离到不同的dll中（根据之前的文章），这些类将实现特定的接口，而该接口将在您的业务登录消费者上声明。然后我建议您实现容器（参见控制反转理论）来解析 dll 实现，这将允许您将业务逻辑实现与消耗分开，并且您将能够毫无困难地用另一个实现替换某些实现。
我捍卫使用 IoC 提供者，而不是直接使用业务管理器类（想想可能会导致噩梦的引用）。该解决方案解决了dll的隔离及其优化消耗的问题。
I suggest you to separate your business logic into different dll's in accordance to their pertence (in accordance with previous post), these classes will implement specific interface while this interface will be declared on you business login consumer. Then I suggest you to implement the containers (see Inversion of Control theory) to resolve dll implementation, this will allow you to separate business logic implementation from consumption and you will be able to replace some implementation by another, without difficulty.
I defend the use of provider with IoC and not the consumption of business manager classes directly (think about references which can result in nightmare). This solution resolves the problem of dll's isolation and their optimized consumption.
听起来您有通用的业务逻辑，一般适用于您的组织，并且每个部分或部门都有更具体的逻辑。您可以以某种方式设置代码，以便每个部门。仅取决于它们的特定逻辑，该逻辑在幕后使用“基本”逻辑中的任何通用功能。为此，您可以设置以下项目：
请注意，每个项目都可以是一个单独的项目，其中编译为自己的程序集。一个部门只需要使用自己的程序集。
就数据访问而言，您可以在基本 BLL 中拥有通用数据访问例程。您的特定 BLL 可以有自己的专用数据查询，这些数据查询会汇集到基础 BLL，而基础 BLL 又使用通用 DAL 并将结果返回到链上。
It sounds like you have common business logic, that applies the your organization in general, and more specific logic per section or department. You could set up your code in a way so that each dept. only depends on their specific logic, which behind the scenes uses any generic functionality in the "base" logic. To that end, you could set up the following projects:
Note that each of these can be a separate project, which compiles to its own assembly. A department would only need to use their own assembly.
As far as data access goes, you can have generic data access routines in your base BLL. Your specific BLLs can have their own specialized data queries that are funnelled to the base BLL, which in turn uses the generic DAL and returns results back up the chain.