Is it possible to make asynchronous InitializeComponent? Otherwise could I load my WPF component asynchronously? More specifically I'm currently developping a product in WPF and I noticed that the loading time of graphical components (some components) is quite big when I have performance requirements.
If you create a component on the UI thread so there's no way to put InitializeComponent on another thread, but it can be called asynchronously in the same thread using Dispatcher.BeginInvoke as follows:
Dispatcher.BeginInvoke(new Action(() =>InitializeComponent()));
Related
I noticed that in the Webforms MVP implementation and most other examples, the Presenter usually attaches handlers to View events. Why can't the Views just call methods in the presenter directly? Just wondering, since the whole task of attaching a handler to an event, defining EventArgs for special parameters, checking if the event is null on the view side seems a lot more tedious than just calling a method.
Sure they can, and I find that to be the best middle ground. What you are describing is I believe called Observing Presenter style. This allows you to completely decouple View from the Presenter, making the view less susceptible to changes within presenter. But it also introduces complexity in testing, and that is the reason to use MVP to begin with. I would not bother with this style at all. On very large project we use Encapsulated Presenter style, where View has a reference to Presenter, injected via IoC container, and view just calls methods on the Presenter. Easy to understand, easy to debug, easy to test.
I have noticed that some WPF controls have some decent effects available to them (drop shadow, reflection etc), and was wondering if it was possible to use these WPF controls solely for their available effects?
For example, I have an image manipulation library that resizes and letterboxes disparate sized images but I would like to add drop shadow effects to the resulting images. The WPF image control has this effect available, but how easy is it to use in an environment where there will never be a GUI (console app or ASP.Net library/handler for example).
Thoughts?
Cheers
Moo
You can use them, yes. The only problem is that you have to use them within STA threads, which you probably can't count on happening automagically (e.g., response threads in ASP.NET are MTA).
I'm using WPF controls in a windows service app. I just have to transition to an STA thread before I do my rendering.
Take a look at RenderTargetBitmap. You could do whatever with your WPF component, then render it as a bitmap, and then use that bitmap on your ASP page.
I'm not sure that is the best way of doing it though. Is Silverlight out of question for you?
What feature(s) of ASP.Net MVC can replace the way events can be used in Webforms to support loosely coupled components?
For example, take a simple pager control in Webforms:
A page number is clicked
Pager fires off a "PageChange" event with the new page number
This subscribing page/control received the event and handles initiating a call to fetch and bind new data.
What tools are available in ASP.Net MVC to similarly support
Loose coupling
Component re-usability
Separation of logic for a single page/view (such a very complex "portal" type page).
ASP.NET MVC, and the Model-View-Controller in general, support loose coupling and separation of concerns by keeping the data and code that supports an application separate from the visual "Presentation-layer" markup that is seen by users.
Designed properly, Controllers and Views in MVC can be reused so that the Edit View for an entity can be "embedded" into a related View with no modification.
For example: an Orders View might include an OrdersDetail partial view. That partial view could be replaced with the OrderDetail Edit View that is also available elsewhere within the application.
Separating the Model from the View makes unit testing more effective and less cumbersome by splitting the code from the context of the presentation layer. You don't want to have to reference System.Web to unit test code that fetches data from a database.
MVC does away with events because events for the most part are just an unnecessary layer between what the client is trying to tell the server to do and the server actually doing it.
In the paging example for webforms the client clicks the button, the browser sends the event/viewstate, and the engine fires the ButtonClicked event. You examine the event, determine the client is intending to page, and you execute the paging logic.
In the MVC paradigm the user clicks a button that makes a request directly to the code that executes the paging logic. Since you know what action the button is supposed to invoke when you put it there why go through all machinations of the event firing? In your controller you certainly could fire an event when you get the command but I honestly can't imagine the use case for doing so.
Both methods accomplish the same thing but MVC just removes a layer of complexity.
I've been learning some new features of ASP.NET beyond my current level of comfort, and I'm trying to figure out exactly how custom events can fit in, from a design standpoint. I know how they work, and the observer/subscriber pattern, but it seems that custom events aren't talked about much. It seems like an entire app could be built from registering events and responses all over the place, and yet, we see more controller-type classes that fire bits of code off in a predetermined pattern...it's OOP, and yet still sort of procedural.
So speaking from a design standpoint, when is it best to use events? Are there certain scenarios that they are very handy for, but not much else? Or is it possible to create an app that relies heavily on them, and a programmer can use them as much or as little as they want?
Mostly I'm just curious as to where they fall into "proper" design, as I can easily re-imagine an app or two of mine leaning on them much more as opposed to just firing off controller class logic when a button is clicked.
You don't see as many custom events in asp.net code mostly because the things that can trigger an "event" tend to be things the user did on the client via one of the built-in controls like a button or what-not. The server itself doesn't really "interact" with the code as it executes in an event-driven way though.
One you get a postback goind via one of the regular controls. The execution on the server tends to be very procedural in nature... that is just the pattern that makes the most sense in a stateless request/response environment like the web.
The asp.net page life-cycle and server controls all have lots of events they expose and may fire those OO like aspects are really just supporting what is by its very nature a highly procedural and linear execution path.
Custom Server controls expose custom events just like the built-in controls do so that page developers have a mechanism by which they can interact with the control without tight coupling... so that is where you'll find most custom events. But the cost of making a custom server control is really only worth it if you really do have a lot of different pages where the control might be used.
I often use events in user controls too. while you can treat a user control very similarly to a server control, generally user controls tend to be weak in terms of OO design principals. With user controls, you are usually just trying to gain a little bit of a separation of concern and some encapsulation, but you'll tend to still have a fairly tight coupling between the hosting page and the user control. but still, sometimes a user control may need to signal to the hosting page that some condition has been met, and in those cases a custom event is a good way to handle that signaling with less coupling than directly calling a method on the hosting page.
Mostly I use custom events when building custom controls.
In ASP.Net I don't use custom events much at all, since even with the custom controls I try to rely more on the existing page life-cycle.
In Windows forms almost everything I do is abstracted into a control somewhere, and so I use them quite a bit.
I've done a lot of custom events in ActionScript 3.0. I mention this because its delegate system is fairly similar to .NET.
I was creating an SWF player that could queue up multiple clips at a time. My custom Timeline control would fire ClipEnd events, which my main application would listen for and advance the Playlist. My Playlist would fire NewClip events if either the user advanced to a new clip, or the app automatically did. My app would listen for these and tell the Timeline to start playing the next clip. So my Timeline and Playlist were symbiotically linked via custom events.
In traditional ASP.NET Web Form applications, UserControls are a great way to encapsulate functionality so that it can be reused. However, UserControls don't fit well into the MVC model. They often make heavy use of ViewState and they blur the seperation of concerns that MVC promotes.
My question is, how do you best bundle a piece of functionality so it can be shared across MVC applications?
As an example, consider a from/to date-selector UserControl that:
allows a user to select two dates, either using a javascript overlay or by typing in day, month and year into seperate fields
can be configured to default to either today and tomorrow's dates or to dates of the developer's choosing
validates the dates that comes back from the user to ensure the from date is before the to date
exposes From and To properties that can be accessed by code-behind
How would I best build something like this in .NET MVC so that I can easily reuse it?
Note that to fully emulate User Control's functionality the MVC component would have to manage the submitted form data and validation - not just the presentation.
In general I would agree that user controls are nice in terms of encapsulating UI stuff, but I don't think too much has really changed in MVC. If I remember right re-using user controls across classic Asp.net projects was a pain and was never really the best way to truly create reusable components. Most UI toolkits that you bought for classic ASP.net didn't give you user controls, they gave you essentially server controls and javascript controls.
In your example, I would probably create or find a jquery (or ur framework of choice) plugin that did what you wanted on the client side. You could also build a C# wrapper around it similar to what Telerik did with some of the jquery UI controls. I do think that the word code-behind and even viewstate will disappear from your vocabulary the more you get into MVC.
If you look at what open source projects are out there for MVC you will get your answer in terms of what you should be doing.
The MVC Contrib app adds a lot of features by creating extension methods and helpers. Their grid control is a typical way to create a reusable component that you could use across projects
Telerik, created some extensions that wrap jquery controls and do asset management.
Finally I think if you look to the future, MVC has areas, which if I interpret it right will give you the ability to break your project apart into multiple smaller projects.
Besides what is already suggested, ASP.NET MVC v2 will have generic templated input controls, see here. You can read how other people do similar techniques, for example, here:
We have
exactly 1 method call for generating a
form element, “Html.InputFor”. As
part of that “InputFor”, it examines
an input specification, that collects
the PropertyInfo, any attributes, the
type, any modifiers called, and
selects an appropriate InputBuilder.
Call InputFor(p => p.Id) and Id is a
GUID? That creates a hidden input
element. Call InputFor(p =>
p.Customer.Address) and Address is a
complex type? That looks for a
partial with the same name of the type
Having considered the helpful answers from others, I will have a go at answering my own question.
It seems to me that the key difficulty with emulating UserControls in MVC is that they crosscut the concerns that MVC aims to seperate. The from/to date selector UserControl in my example incorporates elements of Model, View, Control and interation. UserControls' ability to bundle all this together is exactly the reason that they don't fit well into MVC.
That means that to create a psuedo-UserControl in MVC requires four seperate pieces:
A Model class - in this case an Interval class or similar
A PartialView that knows how to render the Model to HTML
A jQuery script to layer interactivity on top of the PartialView's HTML
A ModelBinder that can deserialise postdata into an instance of the Model class.
The ModelBinder is important because it deals with data coming back from the user. Without it, every Controller that wanted to display a to/from date selector in any of its Views would have to know how to assemble the six postdata fields - and how to cope if they were invalid or some were missing.
Two ways that I can think of. A partial view though this doesn't really transfer well from app to app because you are moving around ascx files. Not a big pain but not my flavour.
I prefer to use WebControls. They are super easy in mvc and all you need to do is reference the library in the project and possibly in your config file and there you go.
I think some of the answers have missed out on the postback functionality of controls. One way you could handle that is to pass any generic information via ViewData when rendering your partial view. That could then post back to its own control, which in turn could redirect to the UrlReferrer.
Its a little messy and use of UrlReferrer poses a security risk. But it is one way around the problem
You can create a jQuery plugin.
As user-controls provided in ASP.NET Webforms, MVC provide a lot of ways to make the controls and code that can be reused in other app.
Using Partials If your partial code have some C# logic and render the html using Razor/aspx code then it's bst to maintain them in razor file.
Write JavaScript Functionality as plugin If you maintain your code and write it as better as it can be used in other app then it would be a huge advantage for you. Next time when you work on other app just open this solution copy it and modify it. Write JavaScript code that can be used as plugin maybe take some more brainstorming.
Write Code As a Separate C# library If some code is too common for every app you make.for example you write a member authentication system or some global function (C#) that are used in every app you made then maintain them in a separate solution so it can be used in other app you made whenever you trying to make a new app in future.