在构建n层应用程序时，我应该如何组织我的名称空间?

本文关键字：我的 何组织 空间 我应该 构建 应用程序 | 更新日期: 2023-09-27 18:08:57

所以当我开始尝试用n层架构构建我的网站时，我很担心性能。

一个回答这个问题的人告诉我，如果你应用了一个好的架构，你最终会得到更好的性能。这与编译dll和其他东西有关，但是现在我不确定如何命名我的命名空间。

比如我有数据访问层的主命名空间假设我有这个命名空间作为数据层。DAL

但是现在我在应用程序中有更多的实体需要由这一层服务，每个实体都有自己的小实体。

所以我应该包括所有的数据代码在一个名称空间(DAL)或我应该每个实体有它自己的名称空间，如DAL。E1和DAL。E2或每个主实体或子实体都应该有自己的名称空间，如DAL.E1。c1,木豆。E2, DAL.E3。c1, DAL.E3。c2 . .最后一个问题:DAL本身是否应该包含任何类?

在构建n层应用程序时，我应该如何组织我的名称空间?

这确实是一个主观问题，每个组织都有完全不同或非常相似的模式。没有最好的答案，但有好的和坏的方法。业界的一个常见模式是基于特性来命名库。例如，在我们的一个产品中:

  • ProductName
  • ProductName。激活
  • ProductName.Activation.Service
  • ProductName。核心
  • ProductName。数据
  • ProductName.Data.Customers
  • ProductName.Data.Engine
  • ProductName。仪表
  • ProductName。安全
  • ProductName。ShellUI
  • ProductName.ShellUI.Windows
  • ProductName。Win32
一般来说，遵循类似于。net框架的模式是一个好方法，或者按特性是另一种方法。有些人可能会争辩说，你不想给你的程序集起有意义的名字，这可能会暴露你的应用程序的脆弱部分或引起注意，但你永远不会阻止盗版者成为盗版者。

其他人更喜欢给他们的程序集起很短的名字，即使在今天微软仍然这样做。(例如mscorlib.dll).

我想这完全取决于项目和正在发生的事情。我并不总是遵循相同的经验法则，但99%的时间我遵循一个共同的模式，我以前工作的公司也有他们的固定模式和做法。

就项目内部的逻辑组织而言，祝你好运。与我交谈过的大多数开发者都有同样的想法。"我只是选择了一个结构/名字，然后就这么做了。"当然不是盲目的，而是要有一些思考进去，但是很难有一个最好的方法，只有指导方针。

我的建议是按功能来组织它，因为它使项目管理更容易。您知道Module1处理系统的Part1, Module2处理Part2，以此类推。例如ProductName.Data.dll。在我的项目中，它处理所有数据绑定操作，如设置、首选项和数据库交互，而ProductName. data . engine是允许ProductName的框架。便于与数据层通信的数据。(在本例中为ProductName。引擎是实体框架的东西与其他自定义类和所需的框架部件)。

我想我遵循的另一个经验法则是，如果Module1有许多组成应用程序Part1的部分，我会将它们全部保留在Module1中。除非像ProductName.Data.Engine那样，该特性非常大，否则它适合于自己的库，以便于管理。

总而言之，祝你好运，因为随着项目规模的扩大，组织和结构是一场不断的斗争，但如果你保持每件事都整洁、有组织、容易找到和理解，那么你的项目将很容易管理。

嗯…这更像是一个组织问题。

我通常喜欢按系统上的功能来组织一个名称空间(类、结构体等)中的项，然后，如果需要，按对象类型分组。

例如:

  • App.Domain; //领域实体
  • App.Domain.Authentication;//与认证相关的域实体
  • App.Domain.Repository;//Repository实现
  • App.Domain.Repository.Mapping;//映射(例如，NHibernate HBM)
  • App.Services;//系统的暴露功能
  • App.Controllers;//视图控制器
  • App.Controllers.Flex;//flex专用控制器

性能总是需要考虑的一点，但不是最重要的一点，至少在非实时应用程序中是这样。我认为维护和可靠性是最重要的。

相关文章：