Github user mmiklavc commented on the issue:
https://github.com/apache/metron/pull/970
@justinleet @nickwallen I agree with the proposed plan for this PR's
refactorings. That being said, I have some comments after having more or less
caught up with the thread.
Generally speaking, it's not uncommon to provide an interface that
encompasses all the desired methods for your data access layer. For instance:
- https://martinfowler.com/eaaCatalog/tableDataGateway.html
- https://martinfowler.com/eaaCatalog/dataMapper.html
-
https://www.tutorialspoint.com/design_pattern/data_access_object_pattern.htm
I initially blinked at having the broad assortment of individual (CRUD)
interfaces along with the aggregate ones, but I think that's fine. Not strictly
necessary, but at least the intention is clear.
I think some of the trouble I/we're seeing with these interfaces and the
inheritance is that it seems like there's some code smell around the
abstractions we're using wrt the meta alerts and index. "Index" and "meta
alert" don't seem to be on the same plane of abstraction. Index is a data store
whereas meta alert is a domain model object. I think it's probably time (as a
follow on DISCUSS thread) to map out how we want our access patterns
restructured to better accommodate the request for composition that @nickwallen
pointed out along with addressing the model and DAO abstraction mismatch.
---
