4 ms·
Actually, very similar, since Entity Framework is usually used. Sources implement the IQueriable interface which lets you write queries with method chaining or
by salex89 9y ago
Actually, very similar, since Entity Framework is usually used. Sources implement the IQueriable interface which lets you write queries with method chaining or LINQ. To be honest, it kinda looks better than it is. In reality I find it produces sub-optimum performance and a lot of things can not be done without spilling query logic to the app. Not to mention a lot of linq/method chaining queries cannot be translated to SQL (by the database provider).
- UK-AL 9y agoYou can persist this model using anything you want. You would have some kind adapter/library that handles the persistence. It would take these models, and covert them into your datastore.
- TekMol 9y agoHow would that work in practice? Would this line stay the same: RegisteredCourses.Add(course); And magically trigger an insert in the database?
- UK-AL 9y agoThe repository pattern in the original example would allow you serailise your objects to whatever datastore you want. His object design isn't that great for being persistence ignorant though. I would instead do something like this. Course - Aggregate Root Student - Aggregate Root RegisteredCourse[] - RegisteredCourses - An array objects with date time of registration, and id reference to course. The method for adding a course would simply create a new RegisteredCourse and place it in the registered courses array. _studentRepository.save(student) would be a simple matter converting this in memory representation into sql. I'm not big fan of using lazy loading, and direct references to other aggregates inside of other aggregates. This makes mapping these models without ORM difficult.
- TekMol 9y agoCan you show in real code, what you mean? From the text you wrote, I cannot grok it.