daniel added a comment. In https://phabricator.wikimedia.org/T118860#1813512, @mkroetzsch wrote:
> When things have a conceptual dependency, it is not bad design to have a code > dependency there as well. I agree, but that dependency should be as narrow as possible. The code that creates an HTML link from a SiteLink should have a dependency on an interface that provides a URL for the SiteLink. It should not known about lookups, and definitely not about database. More importantly, the code that tests the render code should know nothing about databases. > I don't think there is any reason to have duplicate code in either solution > -- that's just a matter of coordinating work within the team (not saying it > is easy, but architecture alone will not solve this ...). We have discussed several options and approaches in detail, over months. This is the result. See https://phabricator.wikimedia.org/T112550 and https://phabricator.wikimedia.org/T112547 for some discussion of other approaches. > > Relying on global state like that for conveniance is what MediaWiki is > > doing all over the place, with horrible results for testability and > > modularity > > > Regarding testing, I guess you already have a mock db connection object > anyway (otherwise, how would you test db read operations ...). I don't see a > reason why this solution should be any less modular or testable than what you > propose. There is also no need to have any duplicate code. Because you are proposing strong coupling between rendering/serialization and storage layer code. We do have a mock database for testing database level code. It should not be needed anywhere else. TASK DETAIL https://phabricator.wikimedia.org/T118860 EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: daniel Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331 _______________________________________________ Wikidata-bugs mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
