I'm currently implementing a project using asp.net, c# and the MVP (Model-View-Presenter) pattern. The main purpose of this solution is to deliver a graph to the consumer, to be used by a variety of systems. It is basically a custom graph server.
The view page in this particular case has an MSChart control on it, which has to be dynamically populated and configured based on parameters in the QueryString. This can be as diverse as totally different types of data sets, display modes and so on, using a lot of the properties of the chart control.
Many of these properties are again of types which are particular to the chart control and would require the same dependencies as the chart control itself if they are to be set by the presenter.
I'm trying to figure out the best way to expose the properties to the presenter so it can work its magic.
Should I:
Just expose the whole chart object and live with a system.web type dependency in the presenter project?
Make accessor and translation properties for all of the chart control properties so that I don't have the dependency, but add lots of complexity?
Other, that I haven't thought of?
To me it seems that it would be against the MVP pattern to bubble a display control up into the presenter, but it seems that trying to map all the properties to DTOs or similar would be a lot of work that would add a lot of complexity, and while the solution would be somewhat more loosely coupled, I'm not sure the gain would be worth it in this case.
How would you implement something like this, given MVP?
While doing some more research on this topic, I found the following blog post on adding a Presenter Model to handle complex view controls, to map between the view and the presenter. It actually made a lot of sense to me, and it's an idea I think I'm going to follow up on and try.
http://mikewagg.blogspot.com/2009/01/managing-complexity-with-mvp-and.html
In fact, Martin Fowler has written on this as well:
http://martinfowler.com/eaaDev/PresentationModel.html
Check out Automapper. Makes translating from a Business Object to a View Model almost effortless. The general idea is your View Model should only have primitive system types if possible to avoid formatting/conditionals in your view.
Related
Actually I am trying to structure my project in a clean MVVMV way. Unfortunately to this restriction I need to find a way to set pins to the map without the power DataBinding. One workaround could be to have the View in my ViewModel and set it directly.
Right now I don't have any chance to get the registered view. Does it make sense to extend the XLabs.Forms.Mvvm.ViewFactory?
Before adding a new issue on GitHub, my hope is that there is a better solution to handle such restrictions. I always used MVVM in my (small) WPF projects.
No that doesn't make sense. Your best approach would be to extend the Maps class to make Pins an ObserverableCollection that is bindable.
The new documentation format on the Xamarin site is rather difficult to read and does not provide the information you require at hand like it used to but I believe the Pins object is not bindable.
Take a look at the Xamarin Forms Labs Github project to get an idea of how this can be done. The approach is defined particularly well in the ExtendedPicker classes (here the items are bound to an ObservableCollection).
Edit: A simpler phrasing of this question would be...
Can't I build a full fledged enyo app with readable code while only using Controls to take the place of Components, Kinds, Models, and Collections?
..
I'm learning EnyoJS and I have yet to find a clear comparison between Components, Kinds, Controls, Collections, and Models.
I understand that for example a Control is a Component that by convention refers to a visible DOM element that the user interacts with directly...but so many of these differences among the aforementioned types seem to be by convention rather than enforced by the framework. It seems that any given idea can be expressed as a Component or a Collection or a Model or...
Can you clearly explain the API differences between these types?
Can you show how certain functionality is truly missing from any one of them but present in another?
Wow. That's a big question.
With regards to controls and components, it's not just convention that differentiates the two. Controls are an Enyo Kind that inherits from the Component Enyo Kind. Controls actually contain methods and properties (specifically for dealing with the DOM) that just don't exist in Components. They're not interchangeable.
The documentation on the Enyo web site does a very good job of explaining the difference between Kinds, Components and Controls.
http://enyojs.com/docs/2.4.0/
There's also the API reference, which breaks out for you the various properties, so you can see for yourself all of the properties that exist (and don't exist) in Kinds, Components and Controls.
http://enyojs.com/docs/2.4.0/api.html#enyo.Control
And finally, since Enyo is open source, you can look at the actual source code to see the differences.
Collections and Models are fairly new to Enyo, starting with Enyo 2.4. Their job is to hold data (A Collection is a group of one or more instances of a Model). Models usually contain JavaScript or Enyo Objects, not Components or Controls.
Components make up the skeleton of your app, Controls are the UI for your app and Models contain the data for your app.
Expanding a bit on Art's answer: You can certainly build a fully functional and maintainable app without Models and Collections. Those kinds help with the data binding infrastructure in version 2.4. If you don't wish to use those features, you can build on version 2.2 and only use Controls and its subkinds (e.g. enyo.Input).
Regarding Components, you could easily build an enyo without creating your own Component but you can't avoid using them because it's part of Control's prototype hierarchy. As Art said, the difference between Component and Control is more than convention. The Component kind facilitates the composition of instances of components. Control extends that to support rendering into the DOM and its containment hierarchy. See post from my Enyo Daily series for some (slightly dated) details.
More concretely, if you don't need to render anything into the DOM but you want to encapsulate some logic into something module-like, use Component. If you need a DOM node, use Control or one of its derivatives.
I'm a pretty experienced Flex/.NET developer who is now learning html5/javascript. I've been playing with Ext Core and ExtJS for the last few weeks and I'm interested in whether/how folks are using these libraries to do bi-directional data binding on data that is not list based.
It seems like most of the binding support is directed at binding rows of data to grids. I'm interested in binding UI elements to arbitrary POJOs that are not list-based data.
Maybe I'm just not looking in the right places, but I'm not finding support for this.
I'm really interested in hearing what folks are doing in Ext OR what folks recommend as an alternative.
Although there is no out-of-the-box solution like the #Bindable from Flex for example, Extjs does offer the infrastructure to create bindings.
If you have a look at http://blog.dnet-ebusiness-suite.com/2012/03/data-binding-in-extjs-4-grid-form.html you'll see a demo for this where the models (filter instance and record instance, instances of Ext.data.Model managed or NOT managed by a store) are bound to different views. The functionality is achieved with a thin framework built on top of Extjs.
On the other hand, to bind arbitrary POJOs is exactly the same story, those have to implement an Observable and fire themselves some property change events which can be listened. The blog posts and the framework itself gives a good starting point on how to do this.
Another way/concept is http://www.sencha.com/forum/showthread.php?60809-Ext.ux.data.BindMgr-Databind-Manager which i used with extjs 3 and works fine.
A follow up... I never did find an ExtJS approach and moved on to other js frameworks/approaches and along the way learned about knockout: http://knockoutjs.com/ which is pretty darned awesome!
Are you looking for the BasicForm functionality? (Particularly: loadRecord)
If you want readonly display you can use DisplayFields or disabled TextFields or similar.
Take a look at jQXB , http://www.jqxb.altervista.com. It's seems to provides a very easy and powerfull api to bind data with html elems
Is it considered poor design to create "black box" User Controls that communicate directly with the service layer (to perform CRUD operations, validation, etc)?
By "black box", I mean that they retrieve/persist data independently of the page they are hosted on (using IoC injected services). Each UC can be dropped onto a page and it will just work. Mind you, there is no business logic embedded in any of these UCs whatsoever (that's all in the Domain layer).
This approach was driven by two factors:
Our application has many pages that are essentially variants on the same view (with slightly different layouts).
Furthermore, our UI designer is fond
of allowing discrete parts of a page
to be opened up for editing. Click
here for a poor attempt at
illustrating this concept.
Anyway, it felt like giving the UCs the ability/responsibility to render and persist themselves would do away with quite a bit of code duplication.
If this approach is indeed considered "icky", please feel free to suggest an alternate one that is more appealing (perhaps MVP?) I'm stuck with WebForms for the foreseeable future.
Thanks!
Assuming you correctly implement the MVP pattern for each control in this fashion this is perfectly acceptable IMO.
Personally the way I have solved issues like this is allowing my MVP pattern to have hybrid view presenters that can access many views (think IListView, IEditView) however this would be more problematic to do if they're truly user controls since they half exist outside of the page to start with. If they're user controls with their own tags you can either implement it the way you asked in your quesiton or you need to expose all the possible events to implement the code on your pages.
No, this is actually how one goes about doing good SOA, where you have "stacks" that are relatively tightly coupled horizontally, loosely coupled with other "stacks" of functionality. The stacks are tied from the UI down to the persistence layer. Think how Amazon and EBay have pages, each page is a composite UI, each piece of the UI is independent of the other pieces, but within each piece the layers are dependent upon one another.
I have an ASP.NET web site dedicated to reporting on PBX extension stats. It comprises many report pages, with HTML generated almost purely by code-behind (setting a Label control's Text property instead of using Response.Write), using un-parameterised string literal SQL queries that populate By Reference DataTable parameters.
Maintenance pages at least comprise DataGrids and detail forms, but use the same DAL, on e thing for which can be said is that it supports multiple DB servers, with sub-classes each overriding these access methods with their own string literal queries.
What do I need to consider cleaning up this mess? I've already made an almost obvious decision to use a third party reporting solution, and move the queries to stored procs in their respective DB languages, narrowing the diversity of the different DAL classes, and to separate CSS out to shared files, as lots of it is very hidden in C# files!
For your back-end design, I suggest having a class to represent each main table of your database (i.e. a Report class and a User class, for example). Anything that's not an event handler should go in the back-end class files / namespace.
For your GUI, looks like you're on the right track using ASP.NET controls instead of just streaming your data out to the user. However, you may consider objectifying the areas of the page. For example, one of my favorite tricks is to open semitransparent "popup" panels when requiring user input or a something like the Information Bar when displaying a short message.
Consider AJAX and the AJAX Control Toolkit. It's easy to implement (especially in the case of a rewrite) and provides great flexibility. Specifically, I've found Accordions - sometimes even nested within other Accordions - are excellent at organizing overabundances of information.
Edit:
Note that if you were to use AJAX, you basically can't even consider using response.write anymore.
As far as having too much content on the screen, remember Panels have a "Scrollbar" property and DIVs don't without some heavy changes.
Also, I tend to separate my code files by Namespace; but the popular trend is to do so by Class. This is a better option if you have many Developers or if it's likely several classes within a namespace will be checked out or simultaneously modified by different people.
I would consider ditching any custom written DAL and use one of:
iBATIS.NET
NHibernate
SubSonic
You might even end up dropping sprocs entirely.
If you're daring you could try the redesign using Microsoft's MVC implementation.
Whatever approach you take, make sure you write unit tests prior to refactoring any code, verify the tests pass before and after refactoring.