Add some comments #1
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
YAmikep
reviewed
Nov 8, 2018
| @@ -14,6 +14,7 @@ class DjangoStorage(Storage): | |||
| """Adapter to use Django ORM as a storage backend.""" | |||
|
|
|||
| def create_user(self, user, password): | |||
| # not injecting repo makes it less explicit when testing | |||
There was a problem hiding this comment.
Do you mean what you call repo_provider in your code? So the User.objects here?
YAmikep
reviewed
Nov 8, 2018
| @@ -22,6 +23,7 @@ def create_user(self, user, password): | |||
| django_user = accounts_models.User.objects.from_entity(user) | |||
| django_user.set_password(password) | |||
| django_user.save() | |||
| # nizar: unnecessary coupling with the return from the repo; | |||
There was a problem hiding this comment.
Agreed, I prefer a function that takes a model as an argument and returns the entity.
YAmikep
reviewed
Nov 8, 2018
| @@ -98,6 +100,7 @@ def delete_board_user(self, user_id, board_id): | |||
| raise self.DoesNotExist('User {} is not joined to board {}'.format(user_id, board_id)) | |||
|
|
|||
| django_board_user.delete() | |||
| # nizar: interesting choice here, not sure why it returns this kind of object | |||
There was a problem hiding this comment.
Yeah this should return an entity to be consistent right?
YAmikep
reviewed
Nov 8, 2018
| @@ -5,6 +5,7 @@ | |||
|
|
|||
| from .storage import Storage | |||
|
|
|||
| # nizar: very cool exercise for leveraging the advantages of having a common interface for a repo | |||
There was a problem hiding this comment.
Yeah this makes it clear why you want to abstract the repository so you can switch between django storage and memory storage easily and test the business rules.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Besides my comments and apart from naming the only thing that struct me a bit oddly was the folder structure and file naming. But I see many advantages in having the Entity model folder as the root folder for all the interactors, repository and whatnot. I'd prefer to have the files for each use case/interactor available separately though, for the same reason that I liked the way the Entity named the root folder: visibility over what those files responsibilities.
As I said in the comments, I also see advantages in having more comprehensive and better split tests. Here's a very nice article from Martin Fowler on tests architecture: https://martinfowler.com/articles/microservice-testing/meta-image.phttps://martinfowler.com/articles/microservice-testing/meta-image.png