创建可重用的企业命名空间时的最佳实践
好吧，这件事在我心里已经有一段时间了。我正在为所有常见的中间层对象创建可重用的企业命名空间（类库）。然后，我们的任何开发人员都可以在其项目的开发阶段引用该程序集。这是我的问题。创建包含所有中间层逻辑的单个程序集还是将此功能分解为更小的程序集是否更容易接受？
示例：单个程序集（命名空间示例）
System
System.IO
System.IO.RegEx
System.Net
System.Net.Mail
System.Security
System.Web - AssemblyFull.dll
< strong>示例：多个程序集
System.IO
System.IO.Reg - 编译为 AssemblyIO.dll
System.Net
System.Net - 编译为 AssemblyNet.dll
在过去我已经使用这两种方法完成了此操作，但我想知道其他人都做了什么以及为什么？我不是在寻找任何代码示例，我只是想知道其他开发人员在做什么？
提前致谢。
Alright, this has been on my mind for a while now. I'm in the process of creating a reusable corporate namespace(class library) for all common middle-tier objects. This assembly can then be referenced by any of our developers during the development phase of their project. Here's my question. Is it more acceptable to create a single assembly which consists of all our middle-tier logic or to break this functionality up into smaller assemblies?
Example: Single Assembly(namespace examples)
System
System.IO
System.IO.RegEx
System.Net
System.Net.Mail
System.Security
System.Web - AssemblyFull.dll
Example: Multiple Assemblies
System.IO
System.IO.Reg - Compiles to AssemblyIO.dll
System.Net
System.Net - Compiles to AssemblyNet.dll
In the past I've done this using both methods but I'm wondering what everyone else does and why? I'm not looking for any code examples, I just want to know what other developers have doing?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
作为一般规则，如果程序集没有显式耦合，我会使用它们来分隔它们。例如，如果您有一个低级别的网络 API，以及用于 FTP 相关操作的其他 API，则后者可能取决于前者；但对于 API 用户，您的开发人员；无需在一个组件中同时具备这两种功能；也许一个项目不需要 FTP API，因此它们只需要包含核心“Net”程序集。您可以分离 API，使其尽可能原子化，并避免开发人员在只使用其中一小部分的情况下包含大型程序集。
这种方法的缺点是，如果开发人员需要 FTP 程序集，他们还需要包含 Net 程序集；因此，您必须找到一种方法来管理这些依赖项，从而降低开发人员的复杂性。我在开发 Java 应用程序时使用 Maven（来自 Apache），但到目前为止我还不知道一个好的 .NET 的类似于 Maven 的替代方案。
但是，如果您正在为公司构建一些 API，则可以使用 Wiki 站点或其他轻量级文档工具来解决此问题。
As a general rule, I use to separate assemblies if they are not explicit coupled. For example if you have a low level Networking API, and other API for FTP related operations, probably the later depends upon the former; but for the API user, your developers; there is no need to have both in a single assembly; maybe one project does not require the FTP API, so they only need to include the core "Net" assembly. You can separate APIs in order to be the more atomic as possible and avoid developers to include a big assembly when their will use only a small part of it.
The down side of this approach is that if the developer needs the FTP assembly they also need to include the Net one; so you have to find a way to manage those dependencies that reduces the complexity for developers. I use Maven (from Apache) when doing Java applications but by this date I do not know a good maven-like alternative for .NET.
But if your are building a few APIs for your company, with a Wiki site or other light weigh documentation tool you can address this problem.
我认为这不是正确的答案，但我倾向于对我们所有的库使用通用的命名方法。
我有一个库可以处理许多中间层功能，有点像大多数应用程序会使用的常见任务。
Web.信用卡
Web.CreditCard.Authorization
Web.CreditCard.Charge
Web.CreditCard.Batch
Web.Store.Order
网上商店实体
网上商店.购物车
Web.Store.Auth
Web.User.Auth.OpenID
Web.User.Auth.OAuth
Web.用户.帐户
Web.User.Preferences
因此，无论您构建哪种类型的项目，您都可以重用它们并快速识别它们。其中一些有自己的接口，可以继承和重载，以根据项目需求添加更多功能。
I dont think their is a right answer for this but I tend to use a common naming approach for all of our libraries.
I have a library that handles a lot of the middle-tier functionality, sort of like common tasks that most apps would use.
Web.CreditCard
Web.CreditCard.Authorization
Web.CreditCard.Charge
Web.CreditCard.Batch
Web.Store.Order
Web.Store.Entities
Web.Store.Cart
Web.Store.Auth
Web.User.Auth.OpenID
Web.User.Auth.OAuth
Web.User.Account
Web.User.Preferences
So it don't matter which type of project your building you can reuse them and identify them really quick. Some of them have their own interfaces and can be inherited and overloaded to add more functionality depending on the project requirements.
感谢所有回答这个问题的人。由于每个项目都是不同的，并且几乎不可能得出正确的答案，因此我将描述我将如何解决这个问题。
首先：
我需要确定哪些业务/中间层对象将在所有项目中使用。确定这些后，我将创建一个程序集 [company].common 或 [company].common.util >。我们当前和即将开展的每个项目都将参考这些内容。
第二：
识别更特定于项目的对象。这些程序集可能会被引用，也可能不会被引用。一个例子是[company].security.cryptography。
第三：
确保每个对象都有完整的文档记录，以便未来的开发人员拥有正确维护和引用正确程序集所需的知识。
我想感谢大家这么快就回复我。这是我在 SO 上发表的第一篇文章，但我可以向您保证，您很快就会在这里再次见到我。再次感谢。
Thanks to everyone who replied to this question. Since each project is different and it's nearly impossible to come up with a correct answer I'll describe how I'm going to approach this.
First:
I need to identify which business/middle-tier objects are going to be used in all projects moving forward. Once these have been identified I will create an assembly [company].common or [company].common.util. These will be referenced for each of our current and up-coming projects.
Second:
Identify the objects that are more project specific. These assemblies may or may not be referenced. An example would be [company].security.cryptography.
Third:
Make sure that each object is well documented so that future developers will have the knowledge needed to properly maintain and reference the correct assemblies.
I wanted to thank everyone for getting back to me so quickly. This was my first post on SO but I can assure you that you'll see me here again very soon. Thanks again.
我对可重用文件使用了不同的方法。
我创建了一个单独的解决方案，其中包括所有可重用组件、测试等。
每个可重用“事物”（类、函数、UserControl、图标等）都位于单独的文件中。
需要可重用部分的某些功能的项目只需直接链接到源文件。 （“添加现有项目”、“添加为链接”）。为了方便起见，我将所有重用的部分放在 VS 中的“实用程序”文件夹中（真正的实用程序文件夹是空的，因为文件是链接的）
此设置允许我：
唯一的缺点是，如果您需要手动添加添加的功能所获得的任何依赖项（例如另一个可重用组件或程序集），
因为我不使用不同的程序集，所以命名空间仅遵循以下功能：
I used a different approach for reusable files.
I create a separate solution that includes all reusable components, test etc.
Each reusable "thing" (class, function, UserControl, icon, etc) is in a separate file.
The projects that need some functionality from the reusable part just link directly to the source file. ("Add existing item", "Add as link"). For convenience I place all reused parts in a "utilities" folder in VS (the real utilities folder is empty since the files are linked)
This setup allows me to:
The only drawback is that if you manually need to add any dependencies the added functionality got (e.g. another reusable component or an assembly)
Since I don't use different assemblies, the namespace just follows the function: