د Raiffeisenbank .NET پراختیا کونکي ټولنه په لنډه توګه د ViennaNET مینځپانګې بیاکتنې ته دوام ورکوي. په دې اړه چې څنګه او ولې موږ دې ته راغلو، .
پدې مقاله کې ، موږ به د توزیع شوي لیږدونو ، کتارونو او ډیټابیسونو سره کار کولو لپاره تر اوسه پورې په پام کې نیول شوي کتابتونونو ته لاړ شو ، کوم چې زموږ د GitHub ذخیره کې موندل کیدی شي () ، او .
ViennaNET.Sagas
کله چې یوه پروژه DDD او microservice معمارۍ ته واړوي، بیا کله چې د سوداګرۍ منطق په مختلفو خدماتو ویشل کیږي، د ویشل شوي لیږد میکانیزم پلي کولو اړتیا پورې اړوند ستونزه رامینځته کیږي، ځکه چې ډیری سناریوګانې اکثرا په یو وخت کې څو ډومینونه اغیزمنوي. تاسو کولی شئ د داسې میکانیزمونو سره په ډیر تفصیل سره آشنا شئ، د بیلګې په توګه، .
زموږ په پروژو کې، موږ یو ساده مګر ګټور میکانیزم پلي کړی دی: یو ساګا، یا د آرکیسټریشن پر بنسټ ساګا. د دې جوهر په لاندې ډول دی: د سوداګرۍ یو ځانګړی سناریو شتون لري چې په کې اړینه ده چې په ترتیب سره په مختلف خدماتو کې عملیات ترسره کړئ ، او که چیرې په کوم ګام کې کومه ستونزه رامینځته شي ، نو اړینه ده چې د ټولو تیرو مرحلو لپاره د رول بیک پروسیجر ته زنګ ووهئ ، چیرې چې دا دی. چمتو شوی. په دې توګه، د ساګا په پای کې، د بریالیتوب په پام کې نیولو پرته، موږ په ټولو ډومینونو کې ثابت معلومات ترلاسه کوو.
زموږ پلي کول لاهم په خپل لومړني شکل کې رامینځته شوي او د نورو خدماتو سره د متقابل عمل هیڅ میتود کارولو پورې تړاو نلري. کارول یې ستونزمن نه دي: یوازې د ساګا بیس<T> د خلاصې ټولګي نسل جوړ کړئ ، چیرې چې T ستاسو د شرایطو ټولګي ده چیرې چې تاسو کولی شئ د ساګا کار کولو لپاره لومړني معلومات ذخیره کړئ ، او همدارنګه ځینې مینځنۍ پایلې. د شرایطو مثال به د اجرا کولو پرمهال ټولو مرحلو ته تیریږي. ساګا پخپله یو بې ریاسته طبقه ده، نو مثال په DI کې د یو واحد په توګه کیښودل کیدی شي ترڅو اړین انحصار ترلاسه کړي.
بېلګه اعلان:
public class ExampleSaga : SagaBase<ExampleContext>
{
public ExampleSaga()
{
Step("Step 1")
.WithAction(c => ...)
.WithCompensation(c => ...);
AsyncStep("Step 2")
.WithAction(async c => ...);
}
}
بیلګه تلیفون:
var saga = new ExampleSaga();
var context = new ExampleContext();
await saga.Execute(context);
د مختلفو تطبیقونو بشپړ مثالونه لیدل کیدی شي او سره په مجلس کې .
ViennaNET.Orm.*
د Nhibernate له لارې د مختلف ډیټابیسونو سره کار کولو لپاره د کتابتونونو سیټ. موږ د Liquibase په کارولو سره د DB-لومړی طریقه کاروو، نو په چمتو شوي ډیټابیس کې د ډیټا سره کار کولو لپاره یوازې فعالیت شتون لري.
ViennaNET.Orm.Seedwork и ViennaNET.Orm - اصلي مجلسونه چې په ترتیب سره لومړني انٹرفیسونه او د دوی پلي کول لري. راځئ چې د دوی محتويات په ډیر تفصیل سره وګورو.
د ليدنمخ IEntityFactoryService او د هغې پلي کول EntityFactoryService د ډیټابیس سره د کار کولو اصلي پیل ټکی دی، ځکه چې د کار واحد، د ځانګړو ادارو سره د کار کولو ذخیره، او همدارنګه د امرونو اجرا کونکي او مستقیم SQL پوښتنې دلته رامینځته شوي. ځینې وختونه دا اسانه ده چې د ډیټابیس سره کار کولو لپاره د ټولګي وړتیا محدوده کړئ ، د مثال په توګه ، یوازې د معلوماتو لوستلو وړتیا چمتو کول. د داسې قضیو لپاره IEntityFactoryService یو پخوانی - انٹرفیس شتون لري IEntityRepositoryFactory، کوم چې یوازې د ذخیره کولو رامینځته کولو لپاره میتود اعلانوي.
ډیټابیس ته مستقیم لاسرسي لپاره ، د چمتو کونکي میکانیزم کارول کیږي. هر DBMS چې موږ یې په خپلو ټیمونو کې کاروو خپل پلي کول لري: ViennaNET.Orm.MSSQL, ViennaNET.Orm.Oracle, ViennaNET.Orm.SQLite, ViennaNET.Orm.PostgreSql.
په ورته وخت کې ، ډیری چمتو کونکي په ورته وخت کې په یو غوښتنلیک کې راجستر کیدی شي ، کوم چې اجازه ورکوي د مثال په توګه ، د یو خدمت په چوکاټ کې ، پرته د زیربنا ترمیم کولو لګښتونو څخه ، د ګام په ګام مهاجرت ترسره کړي. یو DBMS بل ته. د اړتیا وړ پیوستون غوره کولو میکانیزم او له همدې امله د ځانګړي ادارې ټولګي لپاره چمتو کونکی (د کوم لپاره چې د ډیټابیس میزونو ته نقشه لیکل کیږي) د BoundedContext ټولګي کې د ادارې راجستر کولو له لارې پلي کیږي (د ډومین ادارو راجسټر کولو لپاره میتود لري) یا د هغې جانشین ApplicationContext (د غوښتنلیک د ادارو د راجستر کولو طریقې لري، مستقیم غوښتنې او امرونه)، چیرې چې د ترتیب څخه د ارتباط پیژندونکی د دلیل په توګه منل کیږي:
"db": [
{
"nick": "mssql_connection",
"dbServerType": "MSSQL",
"ConnectionString": "...",
"useCallContext": true
},
{
"nick": "oracle_connection",
"dbServerType": "Oracle",
"ConnectionString": "..."
}
],
د غوښتن لیک مثال:
internal sealed class DbContext : ApplicationContext
{
public DbContext()
{
AddEntity<SomeEntity>("mssql_connection");
AddEntity<MigratedSomeEntity>("oracle_connection");
AddEntity<AnotherEntity>("oracle_connection");
}
}
که چیرې د پیوستون ID مشخص نه وي، نو د "ډیفالټ" په نوم پیوستون به وکارول شي.
ډیټابیس جدولونو ته د ادارو مستقیم نقشه کول د معیاري NHibernate وسیلو په کارولو سره پلي کیږي. تاسو کولی شئ توضیحات د xml فایلونو او ټولګیو له لارې وکاروئ. د واحد په ازموینو کې د سټب ذخیره کولو اسانه لیکلو لپاره ، یو کتابتون شتون لري ViennaNET.TestUtils.Orm.
د ViennaNET.Orm کارولو بشپړ مثالونه موندلی شئ .
ViennaNET. پیغامونه.*
د کتارونو سره کار کولو لپاره د کتابتونونو سیټ.
د کتارونو سره د کار کولو لپاره، ورته طریقه د مختلفو DBMSs سره غوره شوې وه، د بیلګې په توګه، د کتابتون سره د کار کولو په شرایطو کې ترټولو ممکنه متحد طریقه، پرته له دې چې د قطار مدیر کارول کیږي. کتابتون ViennaNET.Messaging د دې یووالي لپاره دقیقا مسؤل دی، او ViennaNET.Messaging.MQSeriesQueue, ViennaNET.Messaging.RabbitMQQueue и ViennaNET.Messaging.KafkaQueue په ترتیب سره د IBM MQ، RabbitMQ او Kafka لپاره اډاپټر تطبیقونه لري.
کله چې د قطارونو سره کار کوئ، دوه پروسې شتون لري: د پیغام ترلاسه کول او لیږل.
د ترلاسه کولو په اړه فکر وکړئ. دلته دوه اختیارونه شتون لري: د دوامداره اوریدلو او د یو پیغام ترلاسه کولو لپاره. په دوامداره توګه قطار ته غوږ نیولو لپاره، تاسو باید لومړی د پروسیسر ټولګي تشریح کړئ چې له هغې څخه په میراث کې ترلاسه شوي IMessageProcessor، کوم چې به د راتلونکي پیغام پروسس کولو مسؤل وي. بیا، دا باید د یو ځانګړي کتار سره "تړل" وي؛ دا د راجستریشن له لارې ترسره کیږي IQueueReactorFactory د ترتیب څخه د قطار پیژندونکي ته اشاره کول:
"messaging": {
"ApplicationName": "MyApplication"
},
"rabbitmq": {
"queues": [
{
"id": "myQueue",
"queuename": "lalala",
...
}
]
},
د اوریدلو پیل بیلګه:
_queueReactorFactory.Register<MyMessageProcessor>("myQueue");
var queueReactor = queueReactorFactory.CreateQueueReactor("myQueue");
queueReactor.StartProcessing();
بیا، کله چې خدمت پیل شي او طریقه د اوریدلو پیل کولو لپاره ویل کیږي، د ټاکل شوي کتار څخه ټول پیغامونه اړوند پروسیسر ته ځي.
د فابریکې انٹرفیس کې یو واحد پیغام ترلاسه کولو لپاره IMessagingComponentFactory یوه طریقه شته CreateMessageReceiverکوم چې به یو ترلاسه کونکی رامینځته کړي چې ورته ټاکل شوي قطار څخه پیغام ته انتظار کوي:
using (var receiver = _messagingComponentFactory.CreateMessageReceiver<TestMessage>("myQueue"))
{
var message = receiver.Receive();
}
د پیغام لیږلو لپاره تاسو اړتیا لرئ ورته وکاروئ IMessagingComponentFactory او یو پیغام لیږونکی جوړ کړئ:
using (var sender = _messagingComponentFactory.CreateMessageSender<MyMessage>("myQueue"))
{
sender.SendMessage(new MyMessage { Value = ...});
}
د پیغام د سیریل کولو او ډیسیریل کولو لپاره درې چمتو شوي اختیارونه شتون لري: یوازې متن ، XML او JSON ، مګر که اړتیا وي ، تاسو کولی شئ په اسانۍ سره خپل انٹرفیس پلي کړئ IMessageSerializer и IMessageDeserializer.
موږ هڅه کړې چې د هر قطار مدیر ځانګړي وړتیاوې وساتو، د بیلګې په توګه ViennaNET.Messaging.MQSeriesQueue تاسو ته اجازه درکوي نه یوازې متن، بلکې د بایټ پیغامونه، او ViennaNET.Messaging.RabbitMQQueue د لارې کولو او په الوتنه کې قطار کولو ملاتړ کوي. د RabbitMQ لپاره زموږ اډاپټر ریپر هم د RPC ځینې نمونې پلي کوي: موږ یو پیغام لیږو او د ځانګړي لنډمهاله قطار څخه ځواب ته انتظار کوو، کوم چې یوازې د ځواب پیغام لپاره رامینځته شوی.
دلته .
ViennaNET.CallContext
موږ قطارونه نه یوازې د مختلف سیسټمونو تر مینځ ادغام لپاره کاروو ، بلکه د ورته غوښتنلیک مایکرو خدماتو ترمینځ ارتباط لپاره هم کاروو ، د مثال په توګه ، په ساګا کې. دا د دې لامل شوی چې د پیغام سره لیږدولو ته اړتیا وي لکه د کارونکي ننوتل، د پای څخه تر پای پورې د ننوتلو لپاره د پیژندونکي غوښتنه، د سرچینې IP پته او د واک ورکولو ډاټا. د دې معلوماتو د لیږلو پلي کولو لپاره، موږ یو کتابتون جوړ کړ ViennaNET.CallContext، کوم چې تاسو ته اجازه درکوي خدمت ته د ننوتلو غوښتنې څخه ډاټا ذخیره کړئ. په دې حالت کې، د کتار له لارې یا د Http له لارې غوښتنه څنګه شوې، مهمه نده. بیا، د وتلو غوښتنې یا پیغام لیږلو دمخه، ډاټا د شرایطو څخه اخیستل کیږي او په سرلیکونو کې ځای پرځای کیږي. په دې توګه، راتلونکی خدمت مرستندویه معلومات ترلاسه کوي او په ورته ډول اداره کوي.
ستاسو د پاملرنې څخه مننه، موږ ستاسو نظرونو او غوښتنو ته سترګې په لار یو!
سرچینه: www.habr.com