Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Loosely Coupled Associations #32

Open
JeremyCaney opened this issue Mar 5, 2021 · 0 comments
Open

Loosely Coupled Associations #32

JeremyCaney opened this issue Mar 5, 2021 · 0 comments
Labels
Area: Mapping Relates to one of the `ITopicMappingService` interfaces or implementations. Area: Repositories Relates to the `ITopicRepository` interface or one of its implementations. Status 0: Discussion Needs further evaluation of requirements and prioritization. Type: Feature Introduces a major area of functionality.

Comments

@JeremyCaney
Copy link
Member

Currently, an entire topic graph needs to be loaded—typically via the CachedTopicRepository—with all data, and references to in-memory objects, to ensure that the graph can be navigated and mapped via association properties, such as Parent, Children, References, and Relationships.

Consequences

This has a number of downsides:

  • A large amount of data must be loaded up-front and/or persisted in a cache.
  • We cannot evict stale or rarely referenced items from the cache.
  • We cannot have any lazy loading, such that associations get loaded on demand.
  • OnTopic is not optimized for very large data sets, or distributed read/write databases.
  • OnTopic is not optimized for e.g. mobile devices that have limited memory.

Alternatives

An alternative would be to expose a light-weight Topic entity, similar to the TopicData interchange class, which tracks the unique keys of its associations, and then combine it with a service that retrieves those objects by key on demand—either from a data store, or from a cache.

Questions

  • Would this be an entirely separate OnTopic library? Or could it integrate with the existing Topic entity? I assume the former.
  • Would callers need to handle looking up associations? Or would the topic entity accept e.g. a repository as an argument to a method?
  • Could this be implemented via an ITopicMappingService which operates off of an e.g. ITopic{Record?}Repository to dynamically query the database based on the needs of a record?

This is likely to be a massive change in how OnTopic operates. It may be better to accept its limitations and focus instead on its strengths, instead of reinventing much of the library to support scenarios other CMS concepts are better suited for.

@JeremyCaney JeremyCaney created this issue from a note in .NET 5.x Version (Deferred) Mar 5, 2021
@JeremyCaney JeremyCaney added Area: Mapping Relates to one of the `ITopicMappingService` interfaces or implementations. Area: Repositories Relates to the `ITopicRepository` interface or one of its implementations. Status 0: Discussion Needs further evaluation of requirements and prioritization. Type: Feature Introduces a major area of functionality. labels Mar 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: Mapping Relates to one of the `ITopicMappingService` interfaces or implementations. Area: Repositories Relates to the `ITopicRepository` interface or one of its implementations. Status 0: Discussion Needs further evaluation of requirements and prioritization. Type: Feature Introduces a major area of functionality.
Projects
No open projects
.NET 5.x Version
  
Deferred
Development

No branches or pull requests

1 participant