Walkthrough Generated Code Query GetById

BasicCRUD Insert Query with Bridge

Now let us walk through the generated code for the query.

So we need to notice here is that we have an output API model generated for the query. This is where you need to structure your output API model or structure your output in the model.

Here we don't need any message because this is querying directly from the Db and from the current structure we have the controller. Here we have the action and the route that is generated.

public partial class CustomerController : FlexControllerBridge
    {
        /// <summary>
        /// 
        /// </summary>
        /// <returns></returns>
        [HttpGet()]
        [Route("GetCustomerById/{id}")]
        public GetCustomerByIdOutputAPIModel GetCustomerById(string id)
        {
            GetCustomerByIdParams parameters = new GetCustomerByIdParams();

            FlexHostContextInfoBridge hostContextInfo = new FlexHostContextInfoBridge();
            hostContextInfo.Populate<IFlexHostHttpContextAccesorBridge>(_appHttpContextAccessor);
            parameters.SetHostContextInfo(hostContextInfo);

            parameters.Id = id;

            return ProcessCustomerService.GetCustomerById(parameters);
        }
    }

Above is the default route generated for the action. You can change the route the way you want here. We have the GetCustomerByIdParams created for the IProcessCustomerService. So let's go there and see in the query file.

We will see what is there inside here. Also, we have a FlexHostContextInfoBridge inside that so that you can pass your context info that is being procured from context throughout the query and parameters can be accessed in the query. For example, you may need a logged in UserId to be passed for a query, it would be very handy there, and it will also help you to to keep the query class decoupled.

So we are passing the ID that is received from the GetCustomerById to the parameters. So then the control goes to the process service. So the process service which is in turn call the query.

public partial class ProcessCustomerService : IProcessCustomerService
    {
        /// <summary>
        /// YourRemarksForMethod
        /// </summary>
        /// <param name="params"></param>
        /// <returns></returns>
        public GetCustomerByIdOutputAPIModel GetCustomerById(GetCustomerByIdParams @params)
        {
            return _flexHost.GetFlexiQuery<GetCustomerById>().AssignParameters(@params).Fetch();
        }
    }

We will come to the query soon. So in the query file, we have a gate customer by Id params, which in turn is inherited from the Flexi query parameter page.

There is no bus or no message needed here. So if we see the parameter it is passed to the customer, we have it build for fetching the customer. It takes the customer domain model and the output API model, here what it does is also to create a repository for see.

public class GetCustomerById : FlexiQueryBridge<Customer, GetCustomerByIdOutputAPIModel>
    {
        private string _Id;
        private IFlexQueryRepositoryBridge _repoFlex;
        readonly ILogger<GetCustomerById> _logger;
        private GetCustomerByIdParams _params;
        IMapper _mapper;
        IReadDbConnectionProviderBridge _connectionProvider;

        /// <summary>
        /// 
        /// </summary>
        /// <param name="repoFlex"></param>
        /// <param name="logger"></param>
        public GetCustomerById(IFlexQueryRepositoryBridge repoFlex, ILogger<GetCustomerById> logger, IMapper mapper, IReadDbConnectionProviderBridge connectionProvider)
        {
            _repoFlex = repoFlex;
            _logger = logger;
            _mapper = mapper;
            _connectionProvider = connectionProvider;
        }

        /// <summary>
        /// 
        /// </summary>
        /// <param name="id"></param>
        /// <returns></returns>
        public GetCustomerById AssignParameters(GetCustomerByIdParams @params)
        {
            _params = @params;
            return this;
        }

        /// <summary>
        /// 
        /// </summary>
        /// <returns></returns>
        public override GetCustomerByIdOutputAPIModel Fetch()
        {
            var stopwatch = Stopwatch.StartNew();

            var result = Build<Customer>().ProjectTo<GetCustomerByIdOutputAPIModel>(_mapper.ConfigurationProvider).FirstOrDefault();

            Trace.WriteLine($"Query GetCustomerById execution time: {stopwatch.ElapsedMilliseconds} ms");

            return result;
        }

        /// <summary>
        /// 
        /// </summary>
        /// <typeparam name="T"></typeparam>
        /// <returns></returns>
        protected override IQueryable<T> Build<T>()
        {
            _connectionProvider.ConfigureDbConnectionString(_params.GetHostContextInfo());
            _repoFlex.InitializeConnection(_connectionProvider);

            IQueryable<T> query = _repoFlex.FindAll<T>().Where(t => t.Id == _params.Id);
            return query;
        }
    }

    public class GetCustomerByIdParams : FlexiQueryParameterBridge
    {
        public string Id { get; set; }
    }

The queries will use the ReadDb repository by default.

We have done it such that you can have one database for both write and read or you can split the database as you wish, for all the queries usually it is like readily available that you have a second read database separate, similarly it creates a connection provider. You can have the replication configured for a read Db.

It takes the HostInfo and creates your ConnectionProvider and we will have a dedicated chapter on connection providers later. So the current default connection provider will read the connection from your app settings.

The connection string to execute all your database operations is available here.

We use the Build and Fetch pattern here to generate the query.

We recommend using the Automapper ProjectTo() as we have given by default. You can also use select instead of this and also you can change this code and use your select or any other link or Entity framework for working here, but this is our preferred way so that your queries are optimal in terms and fast to execute in terms of the output and the structure of your data.