I have two questions.
1: At the moment I have two model classes that are mapped to two entities in the EF diagram.
How does DDD work with EF because if I decide to split my model classes into smaller specific classes e.g. from 2 to 4. How will EF relate to them?
Will I have to create a seperate DTO to map these four model classes to the two entity models that EF will understand?
Just wondering how other people have managed to get around this issue.
2: EF only recognises models that have public properties. If I change my model class to have behavioural methods like GetName(), SetName(), GetAddress() etc and remove the public properties to be private members then EF throws a wobbly and complains it can not find any properties on my model.
How do I solve this issue? Or would the answer be the same as the first question in that I need to create a DTO that has public properties which map from my model class which EF will use?
I'm just thinking if this is the correct path to take because it seems like a bit of redundant work having to map my DDD model classes to another set of DTO or EF model classes that EF understand.
If I do have to map to the EF classes will they be in the model layer or repository layer?
There are possibilities to map multiple entities to the same table (TPH inheritance, table splitting) but these possibilities must follow strict rules. Otherwise you could end up with scenario where you cannot insert entity to database because it doesn't contain all required columns for the record.
EF (with EDMX) recognizes non public properties as well - EF code fist requires at least property with accessible getter or setter. Moreover those behavioral methods can be redundant because writing your own getter and setter in property has the same meaning.
Related
Suppose if I have 3 entities - User, Skills, Department
and I have repositories corresponding to all of them - UserRepository, SkillRepository, DepartmentRepository.
I understand that the relation mapping between entities i.e. one-one many-many should be specified in the respective entity classes. The question is I want to use all of the 3 entities in a query. How would I do it? A single repository is associated with only one entity right? So, how/where would I write it?
As there are many different ways to specify queries with Spring Data JPA there are various answers to this.
Maybe you don't have to. If entity A references B and you just want to get the Bs with your A you simply use your ARepository to load As and use object navigation to get your Bs. You might read up on eager and lazy loading for more information about how to control this.
If you want referenced entities in the where condition you can use property paths in your query method names: https://docs.spring.io/spring-data/jpa/docs/current/reference/html/#repositories.query-methods.query-property-expressions
If you are using #Query annotations you can do (almost) whatever you want with JPQL. Among others, you may as well navigate properties to use them in where clauses.
In general, you'd put that query in the matching repository based on the primary entity returned.
I was wondering if it is possible to combine DAO and Entity in a single class. e.g.
In rails
If I have table named user then there will be one ActiveRecord User and by using that class I can access access Methods related to DB and user i.e. it has both methods user.name (accessing object properties) and user.save / User.get_all methods (managing DB interactions) in the same class
In Spring/Hibernate Configuration
I have two things: DAO and Entity
Entity: I have User class that is an entity and is mapping Table as POJO, so that I can access methods related to a single user e.g. user.getName()
DAO: I have a DAO in which there are DB interactions e.g. userDAO.save(user) and userDAO.get(id).
Question:
I was wondering if I can create single User class and define User properties and getter/setter inside along with DB interactions so that I can single class as both, i.e. user.getName() (as POJO) and User.get(id)/user.save() (as DAO).
Is this method possible, and why are the complications I might run into, if I start with this approach?
it's called Active Record Pattern . Here is article about topic for JPA . Active Record Pattern . and example https://github.com/ActiveJpa/activejpa
Is this method possible, and why are the complications I might run into, if I start with this approach?
it's :
Cohesion & Coupling
if it's real project , it might become problem to support it
when you have 20 entities it's difficult to decide where to put method into what entity , and also find method that you need as it might be in many places
when you don't use active record pattern you can share entity with web layer , with active record entity can't be Serializable.
code become bigger and bigger
I'm new to MVC. I come from Webforms, by the way I was also using Servicestack ormlite.
I need to know if I can have an MVC project, but the Model section can be in a different assembly, so I can share this assembly with other projects (console app, web api, mvc project).
It is important that the assembly can have the Model section using the servicestack functionality for model(s) definition(I use servicestack ormlite for data layer), so here comes my other question, that servicestack's model(s) definition can it be used for the "views" in the MVC project? ie, the models syntaxis for servicestack is compatible with the strong typed models in the views MVC?
do you have a sample of:
models in external assembly
share models definition for DAL in servicestack(ormlite), and working in the views for the MVC project
Thanks in advance.
OrmLite is very flexible and resilient in what clean POCOs you can use with it, from a previous answer:
Clean POCOs
The complex Data Models stored in OrmLite or Redis doesn't suffer from any of these issues which are able to use clean, disconnected POCOs. They're loosely-coupled, where only the "Shape" of the POCO is significant, i.e. moving projects and changing namespaces won't impact serialization, how it's stored in RDBMS tables, Redis data structures, Caching providers, etc. You're also not coupled to specific types, you can use a different type to insert data in OrmLite than what you use to read from it, nor does it need to be the "exact Shape", as OrmLite can populate a DTO with only a subset of the fields available in the underlying table. There's also no distinction between Table, View or Stored procedure, OrmLite will happily map any result-set into any matching fields on the specified POCO, ignoring others.
Effectively this means POCOs in ServiceStack are extremely resilient and interoperable, so you can happily re-use the same DTOs in OrmLite and vice-versa without issue. If the DTO and Data models only deviate slightly, you can hide them from being serialized or stored in OrmLite with the attributes below:
public class Poco
{
[Ignore]
public int IgnoreInOrmLite { get; set; }
[IgnoreDataMember]
public int IgnoreInSerialization { get; set; }
}
Otherwise when you need to separate them, e.g. more fields were added to the RDBMS table than you want to return, the DTO includes additional fields populated from alternative sources, or you just want your Services to project them differently. At that point (YAGNI) you can take a copy of the DTO and add it to your Services Implementation so they can grow separately, unimpeded by their different concerns. You can then effortlessly convert between them using
ServiceStack's built-in Auto Mapping, e.g:
var dto = dbPoco.ConvertTo<Poco>();
The built-in Auto Mapping is also very tolerant and can co-erce properties with different types, e.g. to/from strings, different collection types, etc.
I'm having a few tables on SQL Server, which have similar structure - int Id and string Value.
This tables linked to main table via foreign key, so I'm wrote a bit of logic for mapping a string values to id's in models in MVC Razor. This feature requires that models used as dictionary implement simple IKeyValue interface with Id and Value, but after updating model from database I can loose interface implementation from models and must write it again.
Any way to automate this?
Are you modifying the auto-generated file? If so, you should not do this, for the exact reason you describe in your question -- it will get overwritten.
All of the classes in the generated file should be partial. You can take advantage of this by creating another class (in a different file, but in the same project), make sure it has the same declaration (and namespace), and have it implement the interface. This way the class will implement the interface, but will not be overwritten the next time you refresh the schema from the database.
I'm new to MVC & EF. I'm developing the MVC project with model first approach. In my project i have different entities like-customer,employee,product,etc. and i created association between them like 1 to many in customer-employee like this. and after creating this association; it is generating navigation property in customer entity i.e, Employees (collection object) for employee entity.
I want to modify this collection class and i want to add some more methods on it. Is it possible? How to do this if possible?
thanks.
The property is generated with ICollection<Employee> type. You can in theory create your own class implementing this interface and initialize the property for example in Employee constructor but the property will still expose the interface. Changing return type of the property requires change in class generator (you should use T4 template which would make this easy task). By changing property's return type to your collection you can lose some EF functionality.