ViennaNET: збир на библиотеки за задниот дел. Дел 2

Заедницата на програмери на Raiffeisenbank .NET продолжува накратко да ја прегледува содржината на ViennaNET. За тоа како и зошто дојдовме до ова, можете да го прочитате првиот дел.

Во овој напис, ќе поминеме низ библиотеки кои допрва треба да се земат предвид за работа со дистрибуирани трансакции, редици и бази на податоци, кои може да се најдат во нашето складиште на GitHub (изворите се тука), и Нуџет пакети овде.

ВиенаНЕТ.Саги

Кога проектот ќе се префрли на DDD и микросервис архитектура, тогаш кога деловната логика се дистрибуира низ различни услуги, се јавува проблем поврзан со потребата да се имплементира механизам за дистрибуирана трансакција, бидејќи многу сценарија често влијаат на неколку домени одеднаш. Можете подетално да се запознаете со таквите механизми, на пример, во книгата „Microservices Patterns“, Крис Ричардсон.

Во нашите проекти имплементиравме едноставен, но корисен механизам: сага, поточно сага заснована на оркестрација. Неговата суштина е како што следува: постои одредено деловно сценарио во кое е потребно последователно извршување на операции во различни сервиси, и доколку се појават некакви проблеми на кој било чекор, потребно е да се повика постапката за враќање назад за сите претходни чекори, каде што е обезбедени. Така, на крајот на сагата, без разлика на успехот, добиваме конзистентни податоци во сите домени.

Нашата имплементација сè уште е направена во нејзината основна форма и не е поврзана со употреба на какви било методи на интеракција со други услуги. Не е тешко да се користи: само направете потомок на основната апстрактна класа SagaBase<T>, каде што T е вашата контекстна класа во која можете да ги складирате почетните податоци потребни за работа на сагата, како и некои средни резултати. Контексната инстанца ќе биде пренесена на сите чекори за време на извршувањето. Самата сага е класа без државјанство, така што инстанцата може да се стави во DI како Singleton за да ги добие потребните зависности.

Пример за реклама:

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. Го користиме пристапот DB-First користејќи Liquibase, така што има само функционалност за работа со податоци во готова база на податоци.

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": "..."
  }
],

Пример ApplicationContext:

internal sealed class DbContext : ApplicationContext
{
  public DbContext()
  {
    AddEntity<SomeEntity>("mssql_connection");
    AddEntity<MigratedSomeEntity>("oracle_connection");
    AddEntity<AnotherEntity>("oracle_connection");
  }
}

Ако ID на врската не е наведен, тогаш ќе се користи врската со име „стандардно“.

Директното мапирање на ентитетите на табелите со бази на податоци се спроведува со користење на стандардни NHibernate алатки. Можете да го користите описот и преку xml-датотеки и преку класи. За практично пишување на складишта за никулци во Unit тестови, постои библиотека ViennaNET.TestUtils.Orm.

Може да се најдат целосни примери за користење на ViennaNET.Orm.* тука.

ViennaNET.Пораки.*

Збир на библиотеки за работа со редици.

За работа со редици, беше избран истиот пристап како кај различните DBMS, имено, максималниот можен унифициран пристап во однос на работата со библиотеката, без оглед на користениот менаџер на редици. Библиотека ViennaNET.Messaging е токму одговорен за ова обединување и ViennaNET.Messaging.MQSeriesQueue, ViennaNET.Messaging.RabbitMQQueue и ViennaNET.Messaging.KafkaQueue содржат имплементации на адаптер за IBM MQ, RabbitMQ и Kafka, соодветно.

Кога работите со редици, постојат два процеса: примање порака и нејзино испраќање.

Размислете за примање. Овде има 2 опции: за континуирано слушање и за примање една порака. За постојано слушање на редот, прво мора да ја опишете класата на процесорот наследена од 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