In my app I have my domain layer and web interface (other layers I will not go into details).
My views, working with ViewModels objects, and the database persist domain objects.
To convert a ViewModel object to a domain object I use AutoMapper.
The problem with the working Breeze is that when I will create a new object var newCust = manager.createEntity('Customer', {name:'Beta'}) this is a domain object, and should be an ViewModel object.
Not all, but in some cases the ViewModel is not similar to the object domain. For example, collections of objects in the domain are: ICollection<Person> while in view model are ICollection<int> int is a PK of person.
Question
How to working with breeze in these cases?
How to make the metadata also manages the structure of my viewmodels so I can create objects of type my ViewModel?
#ridermansb - Because you mentioned AutoMapper, I will assume that your mapping is taking place on the server. You want your server API to expose "ViewModels" (in this case you might call them DTOs) rather than the domain model objects. Sometimes your ViewModels mirror your domain objects exactly; sometimes they don't.
Your client only sees what your API exposes. If this is a BreezeJS client, you will likely treat the ViewModels as client-side entities. They are Breeze entities in the sense that you expect Breeze to query, cache, change-track, and validate them. BreezeJS doesn't know whether these "entities" correspond to server-side DTOs or server-side business objects.
Of course if you're using DTOs/ViewModels, your server code is responsible for translating between the DTO form and the domain object form. Presumably this logic lies somewhere in/between the server-side API layer and the domain layer.
If you have chosen this architecture, you have chosen to deal with the bi-directional translation between ViewModels and domain objects and have embraced all the complexity and hassle that entails. I have no words of advice for you on that score.
So let me rephrase and narrow your question: "How can I get metadata that describe the object model exposed by my server-side API?"
My favorite way (assuming a .NET server) is to let EF do it for me. I create a DbContext that references NOT my domain model classes but rather my ViewModel/DTO classes. Of course these classes would not actually map to a real database. No problem; they don't have to. You will never use this DbContext to access data. You will only use it to generate metadata. You are using EF as a design-time, metadata-generating tool ... and that's it. This is an efficient maintainable approach.
I hope to demonstrate this technique "soon" but I've been mighty busy recently so no promises.
Alternatively, you can write the metadata by hand as described here.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
We are having some philosopical debates in our company about where the calls to the Business Logic should be to perform CRUD operations.
I believe that the Model should consist of your data structure and that the controller should be responsible for populating the data.
My co-worker believes that all population should be done in the model class itself, and simply called by the controller. This keeps the controller neat and clean (but, in my opinion, clutters up the model).
He also believes that any call that returns a Json object should happen in the model, not in the controller. The model would return an array to the controller, which would then return this as a Json object.
What are some different pros/cons to each and is there a right or wrong way to do this?
All business logic should be in the MODEL.
Remember, the responsibilities of each layer are thus:
Controller - bridge between the model and view. Decides where to go next.
View - displays the data, gathers user input
Model - business logic, interface to data store.
One of the biggest gains is in maintenance and (later) expansion. In general:
If you need to change business logic, you should not need to modify your controller or view.
If you change your visual display, you should not need to modify your model or controller.
If you change your workflow, you should not need to modify your view or model.
To do the above, each layer should have no knowledge of the others in order to work properly. For example, the view should receive its data and not need to know anything about where it comes from in order to display it properly. The controller should not need to know anything about the underlying structure of the model in order to interact with it. The model should have no knowledge of how the data is to be displayed (e.g., formatting) or the workflow.
"He also believes that any call that returns a Json object should happen in the model, not in the controller. The model would return an array to the controller, which would then return this as a Json object."
NO. The Model should never format data. It also should not read formatted data. That is polluting the model and moving into the level of hell where business logic = display logic.
JSON (coming in or going out) is just another view. So going out:
Data Store -> Model -> Controller -> View
Coming in:
View -> Controller -> Model -> Data Store
FYI, my primary language is PHP, so you can take this all with grain of salt.
The business business logic in MVC and MVC-inspired patterns has to be in the model layer. And yes, model is supposed to be a layer, not a class or object.
Most of said logic would reside in the domain objects, but some of it would end up in services, which should at like "top-level" structures in model layer, through which presentation layer (views and controller) interact with model layer.
Services also should facilitate the interaction between storage abstractions (data mappers, data access objects, units of work and/or repositories) and the domain objects. These structures would deal with persistent and temporary storage and deal with data integrity.
This sort of separation simplifies both the maintenance and testing of the codebase. You gain the ability to easily test you domain logic, without ever touching database (or any other form of storage.
Controllers (and the equivalent structures from other MVVM and MVP patterns) should be extracting information from user's request and changing the state of model layer (by working with services) and the view.
If you implement MVP or MVVM, then the controller-like components would have additional responsibilities, including data transfer from model layer to view, but in classical and Model2 MVC patterns the view is supposed to be an active structure, which request data from the model layer.
As for generation of JSON, that actually should happen in the view. Views are supposed to contain all (or most, depending on how you use templates) the presentation logic. It should acquire information from model layer (either directly or though intermediaries) and, based on that information, generate a response (sometimes creating it from multiple templates). JSON would be just a different format of response.
There has be huge impact (and mostly - negative) by Rails framework, which was released in 2005th. The original purpose of it was to be a framework for prototyping - to quickly create a throw-away code. To accomplish this they simplified the pattern to the point where the separation of concerns was broken.
They replaced model layer with collection of active record structures, which easy to generate and merged the view functionality in the controller, leaving templates to act as replacement for full blown view. It was perfect solution for initial goal, but, when it started to spread in other areas, introduced large number of misconceptions about MVC and MVC-inspired design patterns, like "view is just a template" and "model is ORM".
Your controller methods should be as thin as possible, which means that data access belongs in the model (or more specifically, a Repository object).
Think of your controller methods as a switch-yard... they are only responsible for delegating tasks to other methods for execution.
If you are writing any Linq code in your controllers, you are creating a dependency that will have to be modified if your site structure changes, and you are potentially duplicating data access code. But GetCustomer in the model is still GetCustomer, no matter where you're calling it from your Controllers. Does that make sense?
Business logic that is more extensive than simply accessing data can be put into its own Business Logic Layer, which is considered part of the Model.
I'm not so sure about the JSON. JSON is just an alternative data representation; if you have a utility method that can transform your data classes to JSON, call GetCustomer from the Model, and perform the transformation to JSON in your controller method.
The Model should handle data access.
From MSDN:
Models. Model objects are the parts of the application that implement
the logic for the application's data domain. Often, model objects
retrieve and store model state in a database. For example, a Product
object might retrieve information from a database, operate on it, and
then write updated information back to a Products table in a SQL
Server database.
In MVC, the model is responsible for handling data access. The pro is that all data access code is encapsulated logically by the model. If you included data access code in the controller you would be bloating the controller and breaking the MVC pattern.
i am a complete newbie to the entity framework,mvc just started with it 3 weeks ago.
From then i have been beating around the bush searching for the right approach.the more i dig the more i get lost...i am afraid that i could not proceed any further with using entity framework in mvc
I m lost and frustrated :(
what i have been trying to do is to use entity framework for the MVC application.For that i have started with creating an School.edmx file(which has School.Designer.cs automatically created for it.I dont have any POCO or any others just plain edmx with designer class).Then through some searching i have found that its bad practice to use entity object as model for view.....
Now the real thing started i have made a viewmodel for an entity object.The thing is i dont really get why i have to use a repository and why do i have to map my entity objects and viewmodel objects.Everytime i search why i have to map i get some links saying how to use automapper and the more i search about repository the more i get lost .i dont even understand it.why do i have to map ...??? and why do i have to use repository.
And now the other thing i ask repeatedly to myself is why do i have to write data annotation again in the Viewmodel class when i have already data annotated it in my designer.cs file (like [Required],[Email] and other annotations)..? WHY to write them again!! (If i dont mention them in viewmodel i dont see the annotations working). Duplication of annotation...?
I am lost and i dont even know where i m now
someone give me the right path to follow
Yours Sincerely,
Lost & Confused Newbie
Don't Fret!
Entity Framework is a big beast of a framework based on another beast of a framework: ADO.NET. It's very difficult to truly understand Entity Framework apart from understanding ADO.NET.
That being said, Entity Framework is the perfect tool in some scenarios. However, you (like many of us) seem to have a disconnect about the roles of EF, ASP.NET MVC, and a Repository.
The thing is, you don't need a repository. You don't even need a view model. You don't need EF. And you don't even need ASP.NET MVC. All of these tools are used to make specific jobs easier. None of them have direct ties to each other, and any of them can be used independently of each other.
A Repository: is used to put certain objects into some persistent place, so that you can get them later. That's really all it is.
ASP.NET MVC: Is an HTTP Handler that takes the requested URL and instantiates a controller class which in turn serves up views. The views display some model, and because the views are interactive, they allow the user to send yet another request, starting the whole thing over again. Because this process is (intentionally, but not necessarily) stateless, some sort of persistence is required. This persistence can be a file on the server, a file database, or in most cases a relational database.
Entity Framework: sits on top of ADO.NET (Microsoft's relational database abstraction framework), and allows you to map objects from a graphical (in memory) form to a relational (in-database) form, and back again. The idea is to allow the developer to easily map objects to and from the database. However, this is not a simple process, and because you're not directly interacting with the database (be it via ADO.NET or not), there is some inherent complexity. One of those complexities is the display of the information.
View Models (asp.net mvc view models): allow models to be displayed in various forms. For instance, we may have a "scholastic record" table, and a "person" table, and together they might form a "student". Because our entities are "ScholasticRecord" and "Person", we cannot (as) simply display the information on the view. For this reason, we create a view model to combine and display the information as a "Student".
View Models also prevents us from accidentally calling "lazy" methods on our entities while in the view, which might query the database. This isn't bad, but it could get confusing, because our view is doing repository-like work (which isn't very [S]OLID).
TLDR;
The reason you're having trouble is probably because you're trying to do everything at once. I would suggest using the tools you know, in addition to maybe one or two that you do not. Try using Entity Framework and ASP.NET MVC together, but don't worry about the Repository pattern just yet. It can be difficult to use EF with a Repository, unless you have a lot of experience with either or both.
ASP.NET MVC Tutorials with Entity Framework:
http://www.asp.net/mvc/tutorials/mvc-music-store
(notice how they use models directly in the view, sometimes)
The thing is i dont really get why i have to use a repository
MVC helps you write code that has a clear separation of concerns. In this case, the repository is meant to how the application interacts with the data storage for a specific entity. If you want a Student entity you call StudentRepository.GetEntity(). If you want to save to save you call the StudentRepository.SaveEntity(Student student).
Why do i have to map my entity objects and viewmodel objects.Everytime i search why i have to map i get some links saying how to use automapper and the more i search about repository the more i get lost.
While you can use these entities directly in your view for simple cases, the problem comes up when you have more complex views - composite views that may need multiple entities, views that need to expose only a subset of an entity or even a subset of multiple entities. So yes, you can just expose your entity directly but I find it easier just to create a separate view model.
Automapper is used to help map from view model to entity. So, instead of writing a lot of
entity.Name = viewModel.Name;
entity.Age = viewModel.Age;
...
Automapper is used to automatically map these properties.
And now the other thing i ask repeatedly to myself is why do i have to write data annotation again in the Viewmodel class when i have already data annotated it in my designer.cs file (like [Required],[Email] and other annotations)..?
You should specify validation logic specific for each view in the view model so that if validation fails at the controller it can stop processing instead of continuing. Even though mapping your view model to an entity and trying to save would be prevented by the entities data annotation, I find it clearer to look at a view and its view model to understand what's going on instead of going from view to view model to entity.
Update:
Take a look at ASP.NET MVC View Model Patterns and How we do MVC – View models. I found them both useful when trying to understand view models.
This question really has larger architectural implications and I welcome any input or suggestions on this:
I'm more of the Martin Fowler school of thought when it comes to OOP. I believe you should be able to directly render domain entities in the UI. If I have a Car entity, I should be able to render it to a webpage. The domain model is a crosscutting concern and not a layer. Treating the domain model as a layer leads to an anemic domain model. I don't believe in DTOs in an OOP architecture.
A view model for me is a way of composing the domain entities required in your view. It's not a DTO. I don't understand what the reasoning behind using a view model like DTO is though it seems like a common thing to do using automapper?
So using the metadata approach I put data annotations on my domain model to give any UI implementation hints on how to render and validate the entities. I like to have a richER domain model.
In MVC3 how can you accomplish this (specifically using the Display data annotation) with a resource file that resides in the UI layer? Is there a native implementation for this or do I need to get creative myself? Or have I gone wrong somewhere in my approach?
I disagree.
For one thing, some of the attributes you will use to specify how an entity property should be displayed on a web page come from the System.Web namespace, not the System.ComponentModel.DataAnnotations namespace. By putting these attributes on properties in your domain model, your domain model is taking a dependency on System.Web. For example, there is the [HiddenInput] attribute that tells MVC3 to render a field as input type="hidden". This is not in System.CompoenentModel.DataAnnotations.
Secondly, I don't believe you need data annotation attributes on your entity properties to have a rich domain model. A rich domain model comes from classes that wrap knowledge in a context. The client application should not need to know anything about the domain in order to use it. You achieve a rich domain model with classes, methods, and properties that describe knowledge using the ubiquitous language. DataAnnotations attributes don't lend themselves well to the ubiquitous language imo. And, your domain is more than just your entities. There are factories, services, and other patterns that you can use to build a rich domain model. A domain with only entities and metadata sounds anemic to me.
Thirdly, you may have an entity that should be rendered in different ways on your web site. When someone searches for a car, you may want to display just the make, model, year, and thumbnail photo. When someone clicks on the search result, you may want to display multiple photos, reviews, etc. If you were to use the UIHint attribute on an entity to tell the web ui how to render the car, you wouldn't be able to have different strategies for rendering the Car in different contexts.
Finally, yes, automapper is really great for DTOing your entities into viewmodels. It essentially lets you populate copies of the entity, disconnected from the domain, targeted for specific UI concerns. Here it is safe to use HiddenInput and UIHint attributes to tell MVC3 how to render data.
Response to comment 1
As far as UIHint, I mentioned it here because it has a special meaning with MVC3 EditorTemplates. In cases where a partial view involves receiving input, what is the composition of the view? Text fields, drop-down lists, and input elements that often correspond to entities and their properties in some aggregate root. You will therefore need some representation of the entities to encapsulate the data. Your DTO can be an aggregate root as well, with depth. You can have a root DTO with scalar properties (text/date/bool), navigation properties (drop-down list) and collection properties (ul/ol/table).
We create a corresponding viewmodels for many entities in an aggregate root, and implement them as views using EditorTemplates. If we ever want to switch to a different EditorTemplate, we can apply UIHint to a viewmodel property. Thus we can tell it to "render a location dto as a google map". Automapper can map navigational and collection properties to corresponding viewmodels, forming as complex a representation of your domain entities as you need for the user.
Forgive me if I misunderstand what you mean by flat dto.
Response to comment 2
A viewmodel dto can flatten out / denormalize some properties (using automapper), if your requirements call for it. For example, consider a University entity. It may have many names in many languages (translations), hinting at a UniversityName entity in the aggregate, with University having a collection of Names (1..n). Of those names, 1 may represent the OfficialName / NativeName, and another may represent the TranslatedName to the user's CurrentUICulture. Other entities in the collection may represent TranslatedNames that the user does not understand, and need not be bothered with.
If you have a view that is only interested in these 2 Names in the collection, you can promote them to first-class properties on the viewmodel:
public class UniversityViewModel
{
public string OfficialName { get; set; }
public string TranslatedName { get; set; }
// ...other properties
}
This is a case where denormalizing part of the entity when converting to a viewmodel dto can make sense. Notice how the viewmodel is anemic -- a bare container for data transfer from a controller to a view. This is perfectly fine, and in fact, encouraged.
Answer to original question
To answer your original question, it helps if you think of your domain model & entities as a layer -- more specifically, a bottom layer. Layered software is easier to understand if you think about the various concerns in an application as having dependencies on other concerns. MVC3 is a presentation / UI layer, and will have dependencies on the layers beneath it -- one of those being your domain layer.
If you want to access a resource file in the UI from the domain layer, you are going in the opposite direction. You would be making a low layer depend on a higher layer. If your domain lib depends on the UI lib for a resource, and the UI lib depends on the domain for entities, you end up with a circular dependency. I think you could probably accomplish it using reflection if you needed to, but in that case, you would be fighting against the framework. MVC and .NET in general may not be the best choice for you if that is the case.
I actually think of resource files as a cross-cutting concern. Our application has i18n sprinkled throughout, and often we find we need the same language text resources in both the domain and the UI.
There is nothing wrong with putting a Display attribute on an entity. But if you want to use resources for it, then either put that resource in the domain layer, or if you feel it doesn't belong there, in a lower layer. That way it can be accessed by both the domain and the UI.
So I ended up putting a resourse file in the domain model and added a custom HiddenFieldAttribute so that I don't have to reference the MVC assembly in the domain model.
I still fundamentally dissagree that a view model is really a DTO and that the domain model should be constructed as a layer. I feel that architecting the application in this way creates abstractions that really have no value. If the domain model was truly a layer then we would build a set of logical interfaces from which to access it, and this we don't do. It's a cross cutting concern.
Thanks to olivehour for an interesting discussion and suggesting that it's okay to place resource file(s) in to domain model assembly.
I wanna restrict model to calling to db only
while controller will call model, libraries or helpers.
I do not want to put logic in controller nor in the model to prepare data for views.
Now the logic for preparing all the arrays for views are done in controller. I am creating a library to separate this part as sometimes i feel it is overloading the controller
Hence, i want to create a library class and make controller build the view data before throwing it to the view. It is not exactly templating.
The thing is i do not know how to name it.. Any good suggestion ?
I am thinking view_builder, ui_builder, ui_components?
Cheers
Here's how I'd layer the app:
View
Controller
Service
Persistence
View is either desktop or browser or mobile-based.
Controller is tightly bound to view. It's responsible for validating and binding input to model objects, calling services to fulfill use cases, and routing the response to the next view.
Services fulfill use cases. They know about units of work, own transactions, and manage connections to resources like databases. They work with model objects, other services, and persistence objects. They're interface-based objects, but can be remoted or exposed as web services - RPC-XML, SOAP, REST or other.
Persistence is another interfaced-based object. The implementation can be relational or NoSQL; the important thing is that the interface expresses CRUD operations for model objects. If you use generics, it's possible to write one interface that works for all.
I wouldn't have model objects persist themselves. I'm aware of the "anemic domain model" pejorative, but I think more exciting behavior should center around the business purpose, not CRUD operations.
Good setup. I also sometimes use CI libraries to work out the kinks in a returned data array before passing it to a view. I also sometimes just use the model.
And good for you for thinking about names - I think all the ones you mention are fine; you could also think about naming your library something like data_structure or array_to_object - or something more specific to your own problem like friend_map or tag_cloud.
My advice: pick a name, and then don't be afraid to change it if something more descriptive comes along or the function of your library evolves into something else. Find+replace is your friend.
Hey guys - here's a question on Zend Framework or better on MVC in general:
I am asking myself for a quiet a long time now, if it is a good idea to push business objects (User, Team, etc.) to my views or if it would be better just to push dump data containers such as arrays to the view for rendering.
When pushing business objects to my view I have a much tighter coupling between the views and my domain model, however, the view could easily do things like foreach($this->team->getUsers() as $user) { ... } which I personally find very handy.
Providing domain model data in dumb arrays to me looks more robust and flexbile but with the costs of that the view cannot operate on real objects and therefore cannot access related data using object's method.
How do you guys handle that?
Thanks much,
Michael
It's better to make your View access a Domain Model object in an object-oriented manner, instead of using the Controller to convert Model data into plain scalars and arrays.
This helps to keep the Controller from growing too fat. See the Anemic Domain Model anti-pattern. The Controller only needs to know what Model to instantiate, passes the request inputs to that Model, and then injects the Model into the View script and renders. Keep in mind that a Domain Model is not a data-access class.
You can also write View Helpers to encapsulate a generic rendering of a Domain Model object, so you can re-use it in multiple View scripts.
Your View should accesses the Domain Model only in a read-only manner. View scripts should not try to effect changes to the Domain Model.
You can also design your Domain Model to implement ArrayObject or other SPL type(s), as needed to make OO usage easy in the View script.
It's true, a large driving motivation of MVC and OO design in general is decoupling. We want to allow each layer to remain unchanged as the other layer(s) are modified. Only through their public APIs do the layers interact.
The ViewModel is one solution to abstract the Model so that the View doesn't need to change. The one I tend to use is Domain Model, which abstracts the details of table design, etc. and supplies an API that is more focused on the business rather than the data access. So if your underlying tables change, the View doesn't have to know about it.
I would expect that if there's a change to the Domain Model, for instance it needs to supply a new type of attribute, then it's likely that your View is changing anyway, to show that new attribute in the UI.
Which technique you choose to decouple one layer from the others depends on what types of changes you expect to be most frequent, and whether these changes will be truly independent changes, or if they will require changes to multiple layers anyway.
The "standard" approach would be to completely prepare the model in the controller (e.g. fetch all teams, including users) and then send that to the View for presentation, but you are not bound by that. The data structures can be whatever you want it to be: Array, ArrayObject or custom Classes - anything you deem appropriate.
I dont use Zend framework, so this is in repsonse to the general MVC Have a look at the ViewModel pattern.
http://www.lostechies.com/blogs/jimmy_bogard/archive/2009/06/29/how-we-do-mvc-view-models.aspx
I'm comming from a .Net MVC point of view but I believe the concepts will the same.
I will do all my view rendering in the controller bascially like below
model only output dataset/objects (this should contain the most code)
controller assign view and add necessary HTML and make use of models
view only contains placeholder and other presentation stuff and maybe ajax call
So my team can work on each part without interrupting each other, this also add some information security to the project i.e no one can retrieve all the working code they only communicate by variables/object spec.