domain-model

问题 I have been reading about domain driven design and how to implement it while using code first approach for generating a database. From what I've read and researched there are two opinions around this subject: Have 1 class that serves both as a domain model and a persistence model Have 2 different classes, one implementing the domain logic and one used for a code-first approach Now I know opinion 1) is said to simplify small solutions that do not have many differences between the domain and

问题 Is it reasonable to mix view models with domain models? So i.e. the view model object contains some domain model objects (not the other way around!) 回答1: Generally, you will have to reference your Domain Models in your View Models, or at least load the Domain Models in the controllers and pass the information on to your View Model. I prefer to keep Controllers and Views as simple/dumb as possible, because both Domain Models and View Models are FAR easier to test. So, I often reference my

问题 To take advantage of the wide range of query methods included in java.util.stream of Jdk 8 I am attempted to design domain models where getters of relationship with * multiplicity (with zero or more instances ) return a Stream<T> , instead of an Iterable<T> or Iterator<T> . My doubt is if there is any additional overhead incurred by the Stream<T> in comparison to the Iterator<T> ? So, is there any disadvantage of compromising my domain model with a Stream<T> ? Or instead, should I always

问题 I am studying a Spring book and they mention Java domain model. What is that? 回答1: A domain model (the term is not at all Java specific) is a class that models something in the problem domain, as opposed to a class that exists for technical implementation reasons. Domain model instances often need to be persisted in a database, and in Java, they typically conform to the Java Beans specification, i.e. they have get and set methods to represent individual properties and a parameterless

问题 I stumbled upon the following two articles First and Second in which the author states in summary that ORM Entities and Domain Entities shouldn\'t be mixed up. I face exactly this problem at the moment as I code with EF 6.0 using the Code First approach. I use the POCO classes as entities in the EF as well as my domain/business objects. But I find myself frequently in the situation where I define a property as public or a navigation property as virtual only because the EF Framework forces me