I'm developing some test web-project for my self to learn DDD and good architectural practice at all. So application, basically, is a simple photo manager.
I'm developing 3-tier architecture and for now I have:
- DAL:
- EF database first
- UserRepository
- PhotoRespoitory
- UnitOfWork
BLL
- UserService: user registration, authentication, registration
- PhotoService: photo retrieving, uploading, updating
- DTO Models: User, Photo, Album
- Automapper: mapping DAO from EF to DTO model
Asp.Net MVC Client
Here are examples of DTO models:
public abstract class ModelBase
{
public virtual long Id { get; protected set; }
}
public class User : ModelBase
{
public string Name { get; set; }
public string Email { get; set; }
public UserRole UserRole { get; set; }
public DateTime RegistrationDate { get; set; }
public override string ToString()
{
return $"{Name} {Email} {UserRole} {RegistrationDate}";
}
}
public class Photo : ModelBase
{
public string Name { get; set; }
public DateTime DateTaken { get; set; }
public string Place { get; set; }
public string CameraModel { get; set; }
public string FocalLength { get; set; }
public string Diaphragm { get; set; }
public string ShutterSpeed { get; set; }
public string ISO { get; set; }
public bool? FlashMode { get; set; }
public long OwnerId { get; set; }
public string OwnerName { get; set; }
public long AlbumId { get; set; }
public string AlbumName { get; set; }
}
So my questions are:
Does it make sense to create domain models with some logic, as model manipulation logic was delegated to service?
Is BLL the right place for DTO models?
Do I need to create an additional
ApplicationService
that will containPhotoService
andPhotoService
and finds user that uploads picture and then pass theUserDto
withPhotoDto
toPhotoService
?