Skip to content

lemesevkirill/odata-cli-app

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

1 Commit
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

PeopleApp — TripPin OData Client

A C# application built on .NET 8 to interact with the TripPin OData Service.
The app supports listing users, searching with multiple filters, sorting, and viewing detailed information.

Features

  • List people from the TripPin OData API
  • Filter by first name, last name, username, and region
  • Sort by name fields (ascending/descending)
  • View person details by username
  • Paginated results with customizable page size
  • Command-line interface with interactive input
  • Test coverage for critical paths
  • OData query builder abstraction layer
  • HttpClient with Polly retry policy and timeout handling

Project Structure

PeopleApp/
├── PeopleApp.sln
├── PeopleApp.Cli/       # Console UI and entry point
├── PeopleApp.Core/      # Domain models, DTOs, repositories, services
├── PeopleApp.Tests/     # xUnit tests (repository, service, DTO mapping)

How to Run

dotnet build
dotnet run --project PeopleApp.Cli

Example OData Queries

GET /People?$filter=FirstName eq 'Scott'
GET /People?$filter=AddressInfo/any(a: a/City/Region eq 'WA')
GET /People?$orderby=LastName desc&$top=10&$skip=20
GET /People('russellwhyte')

Running Tests

dotnet test

Tests include:

  • Filtering and sorting logic in repository
  • JSON → DTO → domain mapping
  • GetAsync and SearchAsync repository methods
  • Edge cases (nulls, pagination, invalid input)

Tech Stack

  • .NET 8
  • HttpClient + Polly
  • System.Text.Json
  • xUnit

Notes

  • TripPin API is a public demo and may return errors intermittently
  • Polly is used for retrying transient failures
  • Timeout, exception logging, and query tracing are implemented
  • The application follows a minimal service-repository pattern.
  • The PersonService layer encapsulates decision-making logic about what data projections should be used depending on the query type (e.g., brief list vs. full detail). While the business logic is intentionally thin, this separation ensures future extensibility and maintains clear boundaries between infrastructure and intent.
  • The CLI is wrapped in a minimal loop; commands are extracted for readability. Excess abstractions were deliberately avoided. More config (timeouts, retries, etc.) could have been externalized, but weren’t — for the same reason: it’s a coding assessment, not a product.

Author

This project was developed as part of a technical assignment.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages