Biztalk项目命名约定 [英] Biztalk project naming conventions

查看:80
本文介绍了Biztalk项目命名约定的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

在启动BizTalk项目时,我通常会在此处.您在哪里命名项目和程序集就像:

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

针对其他BizTalk人士的几个问题:

A couple of questions for other BizTalk folks:

1)我通常会发现自己有多个具有模式的项目或需要分离模式的项目.您是否将它们粘贴在单独的程序集中,如果是,则遵循什么约定来命名项目/程序集.如果没有,您是否将它们粘贴在一个程序集中的子文件夹中.

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)我认为,可能是错的,就像上面一样,将项目和程序集命名为BizTalk约定也是一种.我考虑过要避免使用与完整程序集名称相同的名称来命名项目,因此我可能有一个名为Maps的项目,其程序集名为MyCompany.MyProject.Maps.别人这样做吗?

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?

推荐答案

从BTS 2009开始,我们根据项目和程序集所属的应用程序以及可选的子应用程序或关注范围来命名我们的项目和程序集:

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:

MyCompany.Biz.MyFirstApp.dll
MyCompany.Biz.MyFirstApp.Util.dll
MyCompany.Biz.MyFirstApp.ConcernOne.dll
MyCompany.Biz.MySecondApp.dll

我们采用了将业务流程,架构和地图保持在一起的方法,因为多程序集依赖性可能使部署成为真正的麻烦.

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应用程序MyFirstApp

MyCompany.Biz.MyFirstApp.OrderProcessing.dll
MyCompany.Biz.MyFirstApp.Util.dll

BTS应用程序核心

MyCompany.Biz.CORE.OrderProcessing.dll

BTS应用程序MySecondApp

MyCompany.Biz.MySecondApp.OrderProcessing.dll

MyFirstAppMySecondApp都将引用CORE.OrderProcessing中的架构.

Both MyFirstApp and MySecondApp will reference schemas in CORE.OrderProcessing.

更新

MyCompany.Biz.MyFirstApp.OrderProcessing 将包含传入订单文档的消息架构以及用于将它们映射到核心订单消息架构的映射(包含在 MyCompany.Biz.CORE中. OrderProcessing ).如果需要,它还可以包含用于接收消息和(接收)管道组件的业务流程(例如,在处理平面文件时).

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 将包含外发文档的消息模式和一个从核心订单消息模式(到外发)的映射的映射.

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).

在这种基本布局中,CORE仅仅是您内部消息架构的容器,但它将是向订单文档中添加信息的最佳位置-例如,编排为A类客户提供全球折扣(业务规则! ).简而言之,基本上,任何步骤在发送或接收消息时都会执行两次甚至更多次,并且如果要更改传入或传出消息架构或添加新的应用程序,则不想触摸.

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.

这篇关于Biztalk项目命名约定的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆