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.
Related
so many pages and links i found, but none of them have clear answer. Even spring docs doesn't say anything about it.
So which one to use on what context?
Model is an interface that defines methods for adding/removing attributes.
From the javadoc:
Primarily designed for adding attributes to the model. Allows for
accessing the overall model as a java.util.Map.
ModelMap is just a Map implementation used for storing values that will be used in the UI.
ModelAndView is an object that combines a Model object (for storing values that will be used in the UI) and a View (used for resolving UIs components like jsp or templates). It was designed to provide both model and view in a single return.
What do you think about exposing domain entities through services? I tried it in an application, but I came to the conclusion that exposing domain model to the client is not such a good idea.
Advantages:
Really easy to transport data from-to client
List item
(De)Serialization is really easy: just put jackson in the classpath and it will handle it. No extra logic is needed.
No need to duplicate entities POJOs. At least in early stages, the API resources will be pretty much the same as the domain model.
Disadvantages:
The API's get very tightly coupled to the model and you can't change the model without affecting the API
Partial responses. There are cases where you don't want to return all the fields of the entities, just some of them. How do you accomplish it?
So, let's take the following REST example. The following API declares that GET on the user resource returns the following information.
GET
/users/12
{
"firstName":"John",
"lastName":"Poe"
"address":"my street"
}
Usually, I would create a User entity, a user service to return the user and a REST controller to serve the request like this:
#RequestMapping("/users/{id}")
public #ResponseBody User getUser(#PathVariable Long id) {
return userService.findById(id);
}
Should I avoid returning the User entity?
If yes, should I create another class and handle myself the mapping between this class and the entity?
Is there a pattern for this?
How to accomplish partial expansion? (i.e. return only the firstName and lastName for the user)
P.S: using #JSONFilter and ObjectMapper to accomplish partial responses seems too heavyweight to me because you loose the beauty of spring data
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
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 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.