Biztalk 项目命名约定
启动 BizTalk 项目时，我通常遵循此处找到的命名约定。您为项目和程序集命名的位置类似于：
MyCompany.MyProject.Orchestrations.dll
MyCompany.MyProject.Schemas.dll
MyCompany.MyProject.Pipelines.dll
MyCompany.MyProject.Transforms.dll
MyCompany.MyProject.PipelineComponents.dll
其他 BizTalk 人员的几个问题：
1) 我通常发现自己有多个带有架构的项目或需要分离架构。您是否将它们放在单独的程序集中，如果是，那么您遵循什么约定来命名项目/程序集。如果不是，您是否将它们粘贴到一个程序集中的子文件夹中。
2）我相信，这可能是错误的，这是一种 BizTalk 约定，将项目和程序集命名为相同的名称，如上所示。我考虑过不要将项目命名为与完整程序集名称相同的名称，因此我可能将项目命名为 Maps，并将其程序集命名为 MyCompany.MyProject.Maps。其他人也这样做吗？
When starting a BizTalk project I generally follow the naming conventions found here. Where you name your projects and assembly's something like:
MyCompany.MyProject.Orchestrations.dll
MyCompany.MyProject.Schemas.dll
MyCompany.MyProject.Pipelines.dll
MyCompany.MyProject.Transforms.dll
MyCompany.MyProject.PipelineComponents.dll
A couple of questions for other BizTalk folks:
1) I usually find myself having more than one project with schemas or a need to separate schemas. Do you stick them in separate assemblies and if yes, what convention do you then follow for naming the project/assembly. If no, do you stick them in a subfolder in one assembly.
2) I believe, could be wrong, that it's been sort of a BizTalk convention to name the project and assembly the same, like above. I've thought about getting away from naming the projects the same as the full assembly name, so I might have the project named Maps and it's assembly is named MyCompany.MyProject.Maps. Do others do this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从 BTS 2009 开始，我们根据项目和程序集所属的应用程序以及可选的子应用程序或关注范围来命名我们的项目和程序集：
我们采取了将编排、模式和映射放在一起的方法，因为多程序集依赖关系可能会使部署变得非常麻烦。
我们的主要目标是将源系统和目标系统分开以避免直接引用。我们通过为我们正在处理的所有问题引入“核心”组件来实现这一目标：
BTS 应用程序 MyFirstApp
BTS 应用程序 CORE
BTS 应用程序 MySecondApp
两者 < code>MyFirstApp 和
MySecondApp将引用CORE.OrderProcessing中的架构。更新
MyCompany.Biz.MyFirstApp.OrderProcessing 将包含传入订单文档的消息架构以及用于将这些文档映射到核心订单消息架构的映射（包含在MyCompany .Biz.CORE.OrderProcessing）。如果需要，它还可以包含用于接收消息和（接收）管道组件的编排（例如，在处理平面文件时）。
MyCompany.Biz.MySecondApp.OrderProcessing 将包含传出文档的消息架构以及用于从核心订单消息架构（到传出）映射的映射。
在此基本布局中，CORE 只是内部消息模式的容器，但它将是向订单文档添加信息的最佳位置 - 例如，为 A 类客户提供全球折扣的编排（业务规则！）。简而言之，基本上任何步骤在发送或接收消息时都会执行两次甚至多次，并且如果传入或传出消息架构发生更改或添加新应用程序，您不想触及。
Starting with BTS 2009 we named our projects and assemblies according to the application they belong to plus an optional sub-application or concern scope:
We took the path to keep orchestrations, schemas and maps together because multi-assembly dependencies can make deployment a real hassle.
Our main goal was to separate source and target systems to avoid direkt references. We achieved this be introducing "core" components for all concerns we're dealing with:
BTS application MyFirstApp
BTS application CORE
BTS application MySecondApp
Both
MyFirstAppandMySecondAppwill reference schemas inCORE.OrderProcessing.Update
MyCompany.Biz.MyFirstApp.OrderProcessing would contain the message schema for incoming order documents and a map for mapping those into the core order message schema (contained in MyCompany.Biz.CORE.OrderProcessing). If needed it could also contain an orchestration for receiving messages and (receive) pipeline components (when dealing with flat files for example).
MyCompany.Biz.MySecondApp.OrderProcessing would contain the message schema for outgoing documents and a map for mapping from the core order message schema (to outgoing).
In this basic layout CORE will merely be a container for your internal message schemas but it will be the best location to add information to your order documents - for example an orchestration which awards a global discount for class A customers (Business Rules!). In short basically any step you'd do twice or even more times when sending or receiving messages and you do not want to touch if incoming or outgoing message schemas changes or new application is added.
这是来自 Scott Colestock 的精彩 BizTalk 命名约定指南
Here is a wonderful BizTalk Naming Conventions guide from Scott Colestock