Does BreezeSharp support functionality like grouping, sorting, filtering, and navigating a data collection that CollectionView supports?
The use case is similar to the following. A collection of employees for a parent company and it's child companies are retrieved. Based on the company name, the employees need to be filtered (and presented to the UI). Only one company and it's employees are shown at a time.
If Breeze does not support this, should I have my own CollectionView to handle this?
Not quite sure I understand the question. The .NET CollectionView class can certainly be used in conjunction with any collection of Breeze.sharp entities. In addition, all nonscalar breeze navigation properties are live lists, so you won't need to manage the membership of these lists.
Related
In a complicated system you may have business logic related to what a user can see in a given context that you want to re-use across your system.
For example, amazon.com offers different prices to different users depending on a bunch of different rules. Those prices have to be shown consistently in search, product detail pages, email ads, etc.
If you're not yet at the place where it makes sense to extract out internal service APIs, where does this kind of user-specific model logic go in Rails-style MVC? It doesn't belong in the Model (requires too much context), but also doesn't belong in the Controller (needs to be re-used across many views in many controllers).
What are the leading design patterns for this type of problem?
I guess such complex decisions should introduce a ProductService into your system with some PricePipeline inside it. When any part of the system requests a list of products, passing some filters, ProductService fetches products from DB, instantiates PricePipeline manager and passes a list of products with their initial, DB-loaded prices to each member of PricePipeline manager.
Some caching is obviously required, but... that's another question, isn't it? ;)
I'm starting to integrate WebApi & OData into a test bed application. Let's keep it simple and stick with one domain entity, Customer. Obviously I will have an MVC controller. Searching gets it own view model (based on a Lucene index), so that will be separate controller, right now ODataController. But since the view/edit pages will have their own view models, they'd be their own controller. This starts to feel like overkill.
Trying to figure out a good design to make this work and still work with the idea of the URL representing the entity. Should the entity in the URL be Customer and somehow I provide different representations based on URL params? Or should Customer/CustomerSearch/CustomerEdit be different entities (which doesn't sound right)?
I'm presuming that this WebAPI application is going to be a separate solution from the ASP.NET MVC solution you are going to build. In a nutshell, the WebAPI will be the business/domain layer and the MVC will be the presentation layer.
So, in speaking of the WebAPI solution, you only need a single ApiController for the Customer example you presented above. The view/edit request may have their own view models...or not. Depending on how you craft the view model, you may be able to have a single view model for customers, or you could develop a customer view hierarchy where the base view model holds the search-related data and the descendant view model fleshes out the details.
Your routing requests could look like:
GET - /Customer/ retrieve multiple customers
(supplying OData parameters in query string)
GET - /Customer/{id} retrieve a single customer
PUT - /Customer/{id} edit customer
What it looks like is you will need is two routes, one ApiController for Customer, and three request methods for what you described. I don't recommend a separate ApiController for OData, because the functionality is dependent on a entity.
I am interested in general approach for building interactive GUI using MVC3.
The idea is to build set of different components that can be integrated (plugged in) into various scenarios.
Each Component MUST have it's own model definition, controller and views.
Component encapsulates not just the view but also behavior through it's controller.
All internal implementation details, model, behavior, etc... must reside inside component,
so that component becomes independent, modular - black box.
This allows component to be changed without breaking anything in context in which component is used.
Context in which component runs must not make any assumptions about internal details of component implementation.
On the other side the component does not make any assumptions about context in which it will be used.
Finally, the component must provide mechanism to "communicate" or "interact" with outside world. Beside internals, component must provide some kind of "external" interface (like parameters, data, functions, events whatever...) which would allow component to be integrated into execution context.
The Context (or scenario) is part which contains components.
Now, the basic challenge for the context is to manage interaction between components.
Real-world Categories component example:
Component displays list of categories and allows user to perform various actions such as sorting, paging and record selection.
Internally, it has it's own model which stores relevant information like current page, sort, selection, etc...
Internally, it implements all required actions (for basic render, for user actions response, etc...) in it's own controller.
Internally, it handles model state persistence in the view and model state restore in it's own controller.
Real-world Products component example:
Component displays list of products and allows user to perform various actions such as sorting, paging and record selection.
Internally, it has it's own model which stores relevant information like current page, sort, selection, etc...
Internally, it implements all required actions (for basic render, for user actions response, etc...) in it's own controller.
Internally, it handles model state persistence in the view and model state restore in it's own controller.
Real-world Dashboard page (context, scenario) example:
Page displays both Categories and Products components.
Products component displays all products for the currently selected category and thus must provide external interface (parameter or something) to receive selected category identifier from the context.
Categories component must provide some kind of external interface so that context can act when selected category changes and provide selected category identifier for the products component.
Technically, communication approach for page updates would mostly go through AJAX but if this is possible without AJAX, it would be even better.
In the case of AJAX, I would like solution which uses server side controller(s) which decides and renders what should be updated on the client (JSON or something).
I would not like solution in the client script (client side "like" controller) which decides what actions to call and what parts of page to update - this as said in previous paragraph must be decided by controller(s) on the server.
Important: It is not necessarily for the components to work when directly called via some route.
How would you generally implement described system?
I think you need to investigate real projects and see, what approach do you need to use. Try following project and u can find many best practices:
Here u can find implementing of security measures, services, auth and many many useful.
Kigg
http://www.nopcommerce.com/downloads.aspx
http://orchard.codeplex.com/
It's hard to say for me how it's should be implemented. Better to code it. But using of Dependecy Injectction of Views, Controllers, Services, and Repositories are must in your case.
Each controller handles a whole user-machine pattern. That is, roughly, each controller is responsible for orchestrating the user-machine interaction for a user-case(the user-machine patterns that are the result of the analysys phase).
Now if you put "standard behaviours" in controllers who will coordinate the user-machine interaction pattern?
This way you will have "components" without something that coordinate their execution.
In web forms you have pages that coordinates the execution of components put in them...but in Mvc thi coordination role is played by the Controllers themselves.
You can do black-boxes composed of Controllers and Views just if each of them is responsible of a whole user-machine interaction pattern. That is a "Big Components" not a small building blocks, as its is the case when you implement a CMS.
The Orchard CMS use a similar approach. However what you call components are actually pre-defined blocks that play the role of whole sections of the websites being built by the user.
It seems to me that you are trying to achieve something which may not be out-of-the-box compatible with the philosophy of web MVC (other implementations of MVC might support it).
However, if you wanted to go to the trouble of writing a framework on top of ASP MVC, I am sure you could achieve what you want. For example, by using Areas, you could achieve a form of encapsulation of your controllers, view models, and views.
To compose different areas for the same master view, you could write the equivalent of a front controller with its own view that took in a view model - that view model would be primed by the front controller to render actions from the different areas.
You might achieve more mileage by using a client framework such as Backbone.js on top of ASP MVC.
I am trying to create a WCF Data Service that returns objects that look somewhat like my POCOs; they differ insofar as they have a single property which is computed when a query is called.
In other words say I have a POCO Film. I want to be able to query for Films which gives me Films with each with an added property 'IsAllowedToWatch'. The value of 'IsAllowedToWatch' is determined by my authentication state and the number of users currently watching that film.
I'm using Code-First EF4 and WCF Data Services. Can anyone suggest the best way of doing this?
I've solved this problem but the solution was rather convoluted. I had to employ a custom IQueryProvider that mediated between my custom business type and the database type. It all got rather ugly!
Suppose there is a call to get Analytics data from a third party or through our cache data on a server, for the "most popular items", and we show these items' names on all of our pages, should we put this code in Model, Controller, or View (Helper) component?
Maybe it is not strictly Model, because it is not directly in our data store.
Maybe it is Controller... should it be in the "general controller", such as in app/controller/application.rb to be sharable in all views? What if it is obtained in the controller code, but 1 month later, another person follow a new spec and remove the display of it on a view, then the code probably stay at the controller and nobody will remove it.
If it is in the helper... then what if in other part of the code, the controller need to get that data and store it in #popular? Also, aren't helpers suppose to help render data by putting repeated task in methods? So helpers shouldn't do so much data fetching logic.
Where is the code most properly placed?
Although I use .net mvc I think the same principles can apply.
So that being said here is what I usually have:
Controller > Service > Repository code.
So in this case you would have an Analytics service that handles the request and may make calls to third party or may call a repository layer (maybe both) that retrieves data from database. But this way all calls go through the same service. Plus removes any knowledge of how data is retrieved. In fact I had a similar situation one time where we were using a mail client and pulling in some of the analytics from their server and some from our database. All of that was hidden in the service layer so all that was returned was a model that could be used however it was seen fit.
Then all controllers who need it can share. In the view I would then have a helper that displays that data. Again anyone who wants can call the helper and pass the model data in required for that helper. This allows you to apply DRY principle.
Again this works for me. YMMV
I would like to suggest creating a google_api datasource. A quick google search should pop up a few of them that seem half finished to get a start with.
Use the GAPI class from google code from within the datasource to fetch data from google and format the results into something you can use.
Then you can setup a model for each metric you want to track. IE. class GoogleAnalyticsKeyword, GoogleAnalyticsAdWordCampaign etc. These models can be set to use your custom datasource. From the model you can do caching, validation etc on the data.
Then simply reference the models in the uses array in a controller. Either app_controller or dashboard_controller etc. Then just query the models from the controller you need the data to be available from.
http://code.google.com/p/gapi-google-analytics-php-interface/
http://github.com/msadouni/cakephp-plugin-google-analytics
(Disclaimer: this is coming from a Django background, my apologies if the terms or methodology don't directly translate into the MVC framework that you're using.)
My design process would basically go as follows:
I know that I wouldn't want to have to re-calculate the Analytics data for every page hit, so my choice is between just relying on a cache or using a cache in tandem with storing the temporary results in a database. I'd personally go for the latter method.
So I'd setup a Model to handle storing a subset of the Analytics data for the task at hand, saving the "most popular items" in your case. I would then create an automated task (say in cron, or in Django I would use Celery) to aggregate that data on a regular basis, perhaps at midnight every night.
Then I would just write some helpers to quickly query that aggregated data and display it in my template (the View in other frameworks).
In summary, I'd use a combination of the Model and View in the MVC paradigm. I don't see any reason to really involve the Controller in this process.
If you want to place it either Model, View or Controller, I would put it in a Model, because Models are responsible for CRUD actions, and retrieving a list of the most popular items is part of that.
I don't think it has to be in your data storage to count as a Model.
My 2 cents.