If I want to combine using repositorys per entity and Viewmodels per view how does it work out?
Any website tips I could look up? Maby someone could give an easy example?
Thanks
Best Regards!
I like the following structure (from the famous Steven Sanderson's Pro ASP.NET MVC series):
Domain Project (Business Logic):
Abstract Folder (repository interfaces)
Concrete Folder (repository implementations)
Entities (EF generated classes)
Web UI Project (MVC Web App):
Models (view models)
Views
Controlers
etc, you get the point
The main thing is you're separating your business logic (which should house your repositories) from your Web UI (the MVC project)
In this scenario, your Controller classes reference the domain layer and use DI/IoC to call up the correct instance of the repository.
Example controller class:
namespace MyMvcProject
{
using System.Whatever;
using MyDomainLayer;
public class MyController : Controller
{
private readonly IMyRepository _myRepository;
public MyController(IMyRepository myRepository)
{
// Resolved using your favorite DI/IoC Container:
this._myRepository = myRepository;
}
public ActionResult DoSomething()
{
var stuff = _myRepository.GetStuff();
return View(stuff);
}
}
}
Use AutoMapper to copy data from entities to models and vice-versa.
This will reduce a lot of 'plumbing' code you will have to write otherwise.
I'm not a professional developer but I think Steve Sanderson's model is not the right model for some projects because you are working in your views against the model directly. What happen if you want to show only a few properties and not all of them? Your full model is traveling to the view.
I think your views must work against viewmodel classes and not directly the model coming from orm (trough repository, etc.)
The only problem that I'm finding is the mapping process between model to viewmodel and viewmodel to model. Let me explain...
I was trying to do this mapping with automap, the direction between model -> viewmodel works fine, but in the other direction (viewmodel to model) I'm not finding the way to do it automatically because the viewmodel, normally does not own all the properties that model have and if you do an automap to model object a lot of properties are empty.
Finally you need to make always some manual mappings.
Ideas for this situation may be welcome.
Thanks
Related
I have some issue that I want to solve.
I'm using AppService exactly as described in documentation.
[AbpAuthorize(PermissionNames.Pages_Companies)]
public class CompanyAppService : CrudAppService<Company, CompanyDto>
{
public CompanyAppService(IRepository<Company, int> repository) : base(repository)
{
}
}
My issue is that Swagger exposes the real model "Company" and the other models in the model list that is unwanted behavior. I have to hide the real models.
Have a look at screen, all these models from domains layer, and all of them contains appropriate DTO. As I can see swagger doesn't exposes the real Models of Abp itself. Please help to hide my models.
I found the issue. I have exposed the real model inside DTO instead of expose their DTOs in navigation property. This way swagger had to expose my models because they were in use. I've changed my DTOs to use appropriate DTO instead of model inside DTOs. (Sorry for the tautology). Now swagger hides my real models from the model list because they're no longer in use. Problem solved. Hope it helps some one else.
I am using the database first approach with entity framework, when i used to work on the default template the database tables were mapped using the ObjectContext, so i used to create #partial classes & [MetadataType(typeof ) to apply the data annotation ,, but when i start using the Dbcontext code generation template to map the database tables i found that it will create .tt folder in my Model area were i find that i can apply the data annotation directly to the .cs classes themselves without the need to create partial classes as in objectcontext case.
Currently the data annotations are working fine,, but would my approach cause me problems i am not aware of and i should create partial classes as i used to do with the Objectcontext ?
BR
In general, you shouldn't edit generated code because changes you make will be overwritten on re-generation. This is why most generators emit partial classes.
The best practice for your situation would be to create a new file in your solution with another partial class declaration. In that file, add the MetadataType attribute to the class, and add your property-level validation attributes to the "buddy" class (the one referenced in the attribute). This allows you to use validation attributes on the generated properties and, should your model/database change, you can still re-generate your model classes without losing them.
For example, your new file might look something like:
[MetadataType(typeof(PersonMetadata))]
partial class Person
{
// Add logic to the generated class in here.
public string FullName
{
get { return FirstName + " " + LastName; }
}
}
class PersonMetadata
{
// Add attributes to the generated properties in here.
[Required]
public string FirstName { get; set; }
}
Create the same partial classes to define your metadata OR you can simply reverse engineer your existing database using the Entity Framework Power Tools so you have POCO classes. Then you can use the fluent API (you'll see the validations it adds for you) instead of data annotations to give you server side validation.
If you want client side, then you can still apply them to your models, as they wont be regenerated every time you compile .
however - I would recommend you create ViewModels and use AutoMapper to map between your EF objects and viewmodels. Then you can apply your annotations directly to your ViewModels.
My understanding of your situation is that you reverse-engineered your Database-First style to a Code-First style. If your context class inherits from DbContext, you are in Code-First style now (unless there is some strange hybrid possible, which I don't know about!).
In code-first, there is really no point of creating partial classes for data annotations, IMO.
I'm totally stuck.
I've got two Controller: "Customer" and "Address". Both have the fields CustomerRepository and AddressRepository.
There are two ViewModels: CustomerViewModel and AddressViewModel. They also have the fields CustomerRepository and AddressRepository. (And also a parameterless constructor since they are parameters within the edit and create methods)
The Repositories themselves have a DbContext object from my Entities.
Now I'm running into one problem after another. I think I should have only ONE DbContext to share with all of my classes (Repositories AND ViewModels). And I think UnitOfWork is the solution. But I have no clue how to use that.
I currently tried to create a DbContext within the controllers constructor and pass it to every single object requiring it. But even that doesn't work.
If code is necessary, I will post it.
Couple of things to know:
1. Unit of Work
Unit of Work is not necessarily some kind of implementation for IUnitOfWork. It is just a pattern that might be applied in many ways. First, and foremost - you should understand what is it for before actually using it and overcomplicate things around. Moreover, EF Code-First DbContext API's DbContext is a kind of Unit of Work pattern. Your IDbSet<>s are your repositories. Don't try to abstract from your ORM, start with simplest possible thing.
2. DbContext injection
For the beginning, just inject the DbContext to your Controller with constructor injection. Don't forget to setup the IoC container of choice and wire up the MVC's DependencyResolver. Your controller could be look like (example also contains AutoMapper usage example, see next point about ViewModels for that):
public CustomerController : Controller
{
public CustomerController(MyDbContext data, IMappingEngine mapper)
{
Data = data;
Mapper = mapper;
}
public MyDbContext Data { get; set; }
public IMappingEngine Mapper { get; set; }
// Other controller code
}
3. View Models
This, again, is a pattern that is so easily implementable - just have your CustomerViewModel and use AutoMapper to easily transform your Customer to CustomerViewModel so that you can do it like this:
public ActionResult Details(int id)
{
var customer = Data.Customers.FirstOrDefault(c => c.Id == id);
if (customer == null)
return new HttpNotFoundResult();
return View(Mapper.Map<CustomerViewModel>(customer));
}
You can interrogate the AutoMapper's website on how to wire it up and make it running.
Notice that you don't get the ViewModel from DbContext directly. You obtain an "entity" instead which then transformed to appropriate View Model.
Hope this helps!
Your ViewModels should not have references to the DbContext or repositories. ViewModels should be largely stupid. It is the job of the controller (or a service called by the controller) to populate the ViewModels with the data the View needs.
Unit Of work is a good pattern, and one you should use.. but the patern is not a fix for your problem. Your problem is that you are making your view have too much knowledge of your data model.
I currently do the following:
One injected IUnitOfWork using unity to inject into my controllers.
IUnitOfWork implements IContext.
IContext contains IDbSet Customers and IDbSet
The concrete implementation of IContext implements DbContext.
My controllers reference a service, the service uses the IUnitOfWork.
If you use a repository, then simply use a single IContext injected into your controller (or IUnitOfWork which is fairly easy to add on top)
This way I have one context per lifetime of the request and then it's disposed. If you want more code let me know I'll see what I can post up here.
I have several thoroughly unit-tested and finely crafted rich DDD model classes, with final immutable invariants and integrity checks. Object's instantiation happens through adequate constructors, static factory methods and even via Builders.
Now, I have to provide a Spring MVC form to create new instances of some classes.
It seems to me (I'm not an expert) that I have to provide empty constructor and attribute's setters for all form's backing classes I want to bind.
So, what should I do ?
Create anemic objects dedicated to form backing and transfer the informations to my domain model (so much for the DRY principle...) calling the appropriate methods / builder ?
Or is there a mecanisms that I missed that can save my day ? :)
Thank you in advance for your wisdom !
The objects that are used for binding with the presentation layers are normally called view models and they are DTOs purposed toward displaying data mapped from domain objects and then mapping user input back to domain objects. View models typically look very similar to the domain objects they represent however there are some important differences:
Data from the domain objects may be flattened or otherwise transformed to fit the requirements of a given view. Having the mapping be in plain objects is easier to manage than mappings in the presentation framework, such as MVC. It is easier to debug and detect errors.
A given view may require data from multiple domain objects - there may not be a single domain object that fits requirements of a view. A view model can be populated by multiple domain objects.
A view model is normally designed with a specific presentation framework in mind and as such may utilize framework specific attributes for binding and client side validation. As you stated, a typical requirement is for a parameterless constructor, which is fine for a view model. Again, it is much easier to test and manage a view model than some sort of complex mapping mechanism.
View models appear to violate the DRY principle, however after a closer look the responsibility of the view model is different, so with the single responsibility principle in mind it is appropriate to have two classes. Also, take a look at this article discussing the fallacy of reuse often lead by the DRY principle.
Furthermore, view models are indeed anemic, though they may have a constructor accepting a domain object as a parameter and a method for creating and updating a domain object using the values in the view model as input. From experience I find that it is a good practice to create a view model class for every domain entity that is going to be rendered by the presentation layer. It is easier to manage the double class hierarchy of domain objects and view models than it is to manage complex mapping mechanisms.
Note also, there are libraries that attempt to simplify the mapping between view models and domain objects, for example AutoMapper for the .NET Framework.
Yes you will need to create Objects for the form to take all the input, and the update the your model with this objects in one operation.
But I wont call this objects anemic (especially if you do DDD). This objects represent one unit of work. So this are Domain Concepts too!
I solved this by creating a DTO Interface:
public interface DTO<T> {
T getDomainObject();
void loadFromDomainObject(T domainObject);
}
public class PersonDTO implements DTO<Person> {
private String firstName;
private String lastName;
public PersonDTO() {
super();
}
// setters, getters ...
#Override
public Person getDomainObject() {
return new Person(firstName, lastName);
}
#Override
public void loadFromDomainObject(Person person) {
this.firstName = person.getFirstName();
this.lastName = person.getLastName();
}
// validation methods, view formatting methods, etc
}
This also stops view validation and formatting stuff from leaking into the domain model. I really dislike having Spring specific (or other framework specific) annotations (#Value, etc) and javax.validation annotations in my domain objects.
I have the following for a project structure, these are all seperate projects, I was told to do it that way so not my choice.
CORE
--Self Explanitory
DATA
--Contains EF 4.1 EDMX, POCO's Generic Repository Interface
DATAMapping
--Contains Generic Repository
Services
-- Contains nothing at the moment
MVC 3 Application
-- Self Explanitory
Here is my question. I have been reading that it is best practice to keep the controllers on a diet and that models / viewmodels should be dumb therefore introducing the service layer part of my project structure. The actual question now; Is this a good approach or am I creating way too much work for myself?
So if I want to say have some CRUD ops on products or categories or any of the other entities, the repository should be instantiated from the service layer / Business Logic Layer?
Some input please??
Personally I have my service layer referencing only generic and abstract repositories for CRUD operations. For example a service layer constructor might look like this:
public class MyService: IMyService
{
private readonly IFooRepository _fooRepo;
private readonly IBarRepository _barRepo;
public MyService(IFooRepository fooRepo, IBarRepository barRepo)
{
_fooRepo = fooRepo;
_barRepo = barRepo;
}
public OutputModel SomeBusinessMethod(InputModel input)
{
// ... use CRUD methods on _fooRepo and _barRepo to define a business operation
}
}
and the controller will simply take an IMyService into his constructor and use the business operation.
Then everything will be wired by the dependency injection framework of your choice.