如何在严格分层架构中分层，提升模块化而不造成不必要的冗余？ [英] How to break apart layers in a strict-layered architecture and promote modularity without causing unnecessary redundancy?

问题描述

我已经收到了开始为我公司的代码库建立新架构的基础。推动这一举措的事实是：

• 我们的代码基础已经十多年了，最后我们尝试在接缝处打破


• 如果你想打电话给他们，顶层的层是一个经典的ASP和.NET的混乱。


• 我们的数据库充满了一堆不正当的存储过程，其中包含数千行业务逻辑和验证。


• 先前的开发人员创建了不可扩展，不可重用的聪明解决方案展示非常明显的反模式;我们一直在引用，这似乎是可以的。他们把它放在：
  
  
  

  <公司>。（<产品> |<技术>）[。< Feature>] [。< Subnamespace>]

例如，Microsoft.WindowsMo​​bile.DirectX。

  
  

  2.将业务和数据层分解成多个程序集是有益的吗？

  
  

  
  
  

  我绝对认为将业务和数据层分解成多个程序集是有益的。但是，在我的解决方案中，我只创建了两个程序集（DataLayer和BusinessLayer）。其他细节如 Interfaces ，工作流程等，我将在每个程序集下创建目录。我不认为你需要在这个层次上分开它们。

  
  

  3.有接口和抽象类有益对于每个图层在自己的程序集中？

  
  

  
  $ b

  
  

  4.为业务和数据层有一个实体程序集是有益的吗？

  
  

  是的。我会说您的数据实体可能不会直接映射到您的业务模式。将数据存储到数据库或其他介质时，您可能需要更改内容以使其播放不错。您暴露于服务层的实体应该可以用于UI。您使用的实体数据访问层应可用于存储介质。 AutoMapper绝对是你的朋友，可以帮助你提到的映射。所以这就是它的形状：

  
  
  

  服务层详细信息http://i.msdn.microsoft.com/dynimg/IC350997.png

  
  

  I've received the go-ahead to start building the foundation for a new architecture for our code base at my company. The impetus for this initiative is the fact that:

  • Our code base is over ten years old and is finally breaking at the seams as we try to scale.
  • The top "layers", if you want to call them such, are a mess of classic ASP and .NET.
  • Our database is filled with a bunch of unholy stored procs which contain thousands of lines of business logic and validation.
  • Prior developers created "clever" solutions that are non-extensible, non-reusable, and exhibit very obvious anti-patterns; these need to be deprecated in short order.

  I've been referencing the MS Patterns and Practices Architecture Guide quite heavily as I work toward an initial design, but I still have some lingering questions before I commit to anything. Before I get into the questions, here is what I have so far for the architecture:

  (High-level)

  (Business and Data layers in depth)

  The diagrams basically show how I intend to break apart each layer into multiple assemblies. So in this candidate architecture, we'd have eleven assemblies, not including the top-most layers.

  Here's the breakdown, with a description of each assembly:

  • Company.Project.Common.OperationalManagement : Contains components which implement exception handling policies, logging, performance counters, configuration, and tracing.
  • Company.Project.Common.Security : Contains components which perform authentication, authorization, and validation.
  • Company.Project.Common.Communication : Contains components which may be used to communicate with other services and applications (basically a bunch of reusable WCF clients).
  • Company.Project.Business.Interfaces : Contains the interfaces and abstract classes which are used to interact with the business layer from high-level layers.
  • Company.Project.Business.Workflows : Contains components and logic related to the creation and maintenance of business workflows.
  • Company.Project.Business.Components : Contains components which encapsulate business rules and validation.
  • Company.Project.Business.Entities : Contains data objects that are representative of business entities at a high-level. Some of these may be unique, some may be composites formed from more granular data entities from the data layer.
  • Company.Project.Data.Interfaces : Contains the interfaces and abstract classes which are used to interact with the data access layer in a repository style.
  • Company.Project.Data.ServiceGateways : Contains service clients and components which are used to call out to and fetch data from external systems.
  • Company.Project.Data.Components : Contains components which are used to communicate with a database.
  • Company.Project.Data.Entities : Contains much more granular entities which represent business data at a low level, suitable for persisting to a database or other data source in a transactional manner.

  My intent is that this should be a strict-layered design (a layer may only communicate with the layer directly below it) and the modular break-down of the layers should promote high cohesion and loose coupling. But I still have some concerns. Here are my questions, which I feel are objective enough that they are suitable here on SO...

  1. Are my naming conventions for each module and its respective assembly following standard conventions, or is there a different way I should be going about this?
  2. Is it beneficial to break apart the business and data layers into multiple assemblies?
  3. Is it beneficial to have the interfaces and abstract classes for each layer in their own assemblies?
  4. MOST IMPORTANTLY - Is it beneficial to have an "Entities" assembly for both the business and data layers? My concern here is that if you include the classes that will be generated by LINQ to SQL inside the data access components, then a given entity will be represented in three different places in the code base. Obviously tools like AutoMapper may be able to help, but I'm still not 100%. The reason that I have them broken apart like this is to A - Enforce a strict-layered architecture and B - Promote a looser coupling between layers and minimize breakage when changes to the business domain behind each entity occur. However, I'd like to get some guidance from people who are much more seasoned in architecture than I am.

  If you could answer my questions or point me in the right direction I'd be most grateful. Thanks.

  ---

  EDIT: Wanted to include some additional details that seem to be more pertinent after reading Baboon's answer. The database tables are also an unholy mess and are quasi-relational, at best. However, I'm not allowed to fully rearchitect the database and do a data clean-up: the furthest down to the core I can go is to create new stored procs and start deprecating the old ones. That's why I'm leaning toward having entities defined explicitly in the data layer--to try to use the classes generated by LINQ to SQL (or any other ORM) as data entities just doesn't seem feasible.

  解决方案

  I actually just started the same thing, so hopefully this will help or at least generate more comments and even help for myself :)

  1. Are my naming conventions for each module and its respective assembly following standard conventions, or is there a different way I should be going about this?

  According to MSDN Names of Namespaces, this seems to be ok. They lay it out as:

  <Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
For example, Microsoft.WindowsMobile.DirectX.

  2.Is it beneficial to break apart the business and data layers into multiple assemblies?

  I definitely think its beneficial to break apart the business and data layers into multiple assemblies. However, in my solution, I've create just two assemblies (DataLayer and BusinessLayer). The other details like Interfaces, Workflows, etc I would create directories for under each assembly. I dont think you need to split them up at that level.

  3.Is it beneficial to have the interfaces and abstract classes for each layer in their own assemblies?

  Kind of goes along with the above comments.

  4.Is it beneficial to have an "Entities" assembly for both the business and data layers?

  Yes. I would say that your data entities might not map directly to what your business model will be. When storing the data to a database or other medium, you might need to change things around to have it play nice. The entities that you expose to your service layer should be useable for the UI. The entities you use for you Data Access Layer should be useable for you storage medium. AutoMapper is definitely your friend and can help with mapping as you mentioned. So this is how it shapes up:

  Service Layer Details http://i.msdn.microsoft.com/dynimg/IC350997.png

  这篇关于如何在严格分层架构中分层，提升模块化而不造成不必要的冗余？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！