问题
considering the different layers of clean architecture by uncle bob i have a question: if you have your data stored, say in a database, this is obviously a detail so the database goes into the outward layer (framework & drivers). The entities however that describe the data in that database are the core information of my app, so they go in the most inner layer (entities).
Now let's say i have to get all of the data at start of the application. Then there is some computation that is only needed one time at start but that is a bit time consuming. So it is not possible to fetch the data from database all the time. The app therefore works with in-memory representation of that data.
My question is where would you put this in-memory representation? On the one hand it is nothing more than a detail like the database and hence goes in the outer-most layer. On the other hand it represents exactlly the entities with some more information - but in the end it's just a list of plain old objects. This would recommend the core-layer, wouldn't it?
Personally i tend to use the first option and handle it like another datasource - as a detail.
Kind Regards, Thieri
回答1:
The correct answer is "it depends".
There's a huge difference between "theory" and "practice".
Don't get me wrong: "theory" is Good. "Theory" represents "Wisdom", and wisdom is ALWAYS good.
But ...
The "layers" in your "architecture" will necessarily be determined - among other things - by what frameworks you choose to implement your project. Your choices if you're coding in PHP/Codeigniter with MySql are necessarily going to be different than if you're coding in ASP.Net MVC 5 and Entity Framework. They'll be different if you're coding in Java/Spring Boot with Hibernate. They might even be different if you choose to use Hibernate/JPA vs. Hibernate/HQL.
The best approach is to read Robert Martin ... and Alistair Cockburn and Scott McConnell and as many others as you possibly can, try to assimilate their "wisdom" ... and then "choose wisely" when you're faced with an actual project and real-world constraints.
'Hope that helps...
PS, in answer to your question:
If this were a Java Spring Boot/Hibernate project, and I had complete freedom:
I'd implement my "entities" as POJOs
I'd use Hibernate/JPA syntax (e.g. use "EntityManager" et al)
I'd ensure that I could switch between in-memory database (like H2) for testing, vs. an RDMS (like Oracle) simply by changing my application.properties "datasource" configuration file.
In other words, I'd "handle it like another datasource - as a detail" ;)
回答2:
It is still a detail which should be kept in the outer circles. If you think in terms of repository pattern it does not matter whether the implementation is in memory or accesses a SQL database. It remains a detail you want to keep separated from your business logic so that you can change it easily any time you want to.
来源：https://stackoverflow.com/questions/55155740/clean-architecture-which-layer-for-in-memory-entities