Zoran, You and Vladimir Khorikov are my absolute favorite instructors over at PluralSight. I'm glad to find you here on RU-vid! Don't worry, I've already subscribed and hit the notification bell. Good vid (that I'll rewatch a few times). Quick question....am I the only one that doesn't like ORMs? I think I recall a post on your blog where you built you own solution to the data persistence problem. I think I'm a domain purest, not liking the requirement to do special things to the domain objects so that they play nicely with EF or NHibernate. Perhaps you already have a vid that addresses this?
I am glad to hear you liked the video! Regarding ORMs, I lean towards the opinion that they are addressing a hard problem. You can opt to do that using different means, but then it would be your part to address that hard problem, and that is just it. In majority of projects that effort cannot be justified, knowing that the solution already exists - an ORM. It is only in a very narrow set of projects, those that are highly integrated with a particular RDBMS, that an ORM can be dismissed right at the outset. Such integration is often driven by extreme performance requirements, data loads and other services provided by the RDBMS, such as geo distribution, etc. The truth is that in such projects even a custom abstraction layer will be highly unlikely. I have started publishing videos that include Entity Framework, and I plan to continue doing so in the future. There is a plan for making a series of videos dedicated to modeling alone in the near future.
That is a good question! The most important reason for using static factory methods is to give every scenario a name, which constructor cannot have. In that light, a factory named CreateNew is telling loud and clear that the resulting instance is a brand-new object, i.e. not an object that was persisted in an earlier session. Related to this, we can easily define multiple static factory methods, each carrying its own slightly different name and/or list of arguments. We don't fare well doing so with constructors. Multiple constructors that only differ in arguments may be quite confusing. Worse yet, it is not possible to define two constructors with the same argument types. With static factories, that is a common practice. Next reason is validation. Constructor cannot indicate inability to construct an object. All it can do is to throw. However, with static factories, we have an option to return a type which is not just the enclosing class - e.g. return an Option or a Result of the enclosing class. Such static methods are referred to as "smart constructors". They return more information than a constructor can, and thus they make code more explicit, intention-revealing and, after all, harder to make incorrect.
Am I the only one who thinks that your voice sounds a lot like the G-man in Half-Life at times? I imagined that at the end of the video, the light in the room goes out, the door opens, a pillar of light falls on you, illuminating your silhouette in a black suit and with a suitcase in your hands) This could be your trick) Thanks for the interesting videos!
Thanks for this video. It really helped me to understand the Top-Down modeling. Are there any books / resources about this development process (or the concept of developing a vertical slice) ?
Nice video Zoran! Beside your explanation of Top-Down development, how do you approach to domain modeling in real-world scenarios? Do you use this approach or Event Storming sessions? Thanks!
Being a one-man-company, I have no one to storm with on my projects :) And when I do design reviews for companies, the work (or damage!) is already done. Nevertheless, I believe, from what I have heard, that event storming sessions are a good way to get to a common understanding of the domain, and to progress in the direction of separating it into subdomains, i.e. splitting the large problem into smaller ones. The output of event storming sessions is what developers should favor, and wish to have in the first place. Therefore, I agree with that practice.
Parameterless constructor is required by Entity Framework, just like the property setters and the identity property. Those elements are supporting persistence. On the other hand, a parameterless constructor on a class with non-required properties should not be accessible to other callers. Hence, it should be private. Entity Framework is using reflection to access private members it needs.
thank you so much for the clarification, I really like your storytelling style. I have one question. when using ORM, including in this video, most often the data is mapped to the model after it has been received from the database. How about mapping in the model directly in the Select call? for example: db.Books.Select(book => new { book.Title, AuthorName = string.Concat(book.Author?.FirstName, " ", book?.Author?.LastName)}) I understand that the area of responsibility is violated here, but when there is a lot of data, additional mapping is combined with the loading of complete data (Include..ToList) can lead to serious performance brakes
Reconciling a domain model with persistence model is a hard problem in complex applications. Though, in this example here, I would rather keep the logic inside the domain.
Oh, that is an old habit, older than C# :) But now that you made me think of it, I believe I have adopted it for the sake of uniformity. Here is the idea: continue the list: Array.Empty, List.Empty, BankAccount.Empty, Garage.Empty, string...
