MVC 3 IoC Container Causes both Client and Server Validation Problems - inversion-of-control

We have recently upgraded a project to MVC 3 Tools and discovered that our inversion of control container is causing problems with the native MVC model binding validation on both client- and server-side. When we have the IoC hooked up the client validation fails to fire at all and the "IsValid" test in the controller fires erratically and passes along data when it should not.
The only way we've been able to correct the validation framework is to disable the IoC completely. We were using Ninject when the issue first arose but we've also tried StructureMap and Unity and encountered the exact same behavior. We're thinking the issue may reside in IDependencyResolver itself, but that is just a guess. We've also tried disabling all 3rd party tools (Telerik) but the issue seems to only be in the IoC.
My questions for the community: has anybody else experienced validation problems when using IoC in MVC? I would be most grateful for any guidance on this issue. Many thanks.

Related

Why we needed two different approach in ATG -pull based(droplet) and push based(formhandlers)?

I know the question is about solving the problem probably by different approach but let me specify in details what I want to ask and how much I understand about it.
We have two mvc approach used in ATG(or many other framework) pull based and push based.
As I understand it formhandlers and droplet both are playing the part of controller in different need, repositories are our model and jsps are providing views..
And if i am right till this point then what purpose the servlet chain is solving?How it fits into this picture of MVC?
Please If possible explain with the help of flow diagram from request to response (end to end).
Thanks a lot in advance to experts.
Please help.I could not find this kind of explanation anywhere.
The first thing to remember with ATG is that it is an old platform. So when trying to understand the different mechanisms through an MVC lens, remember that nothing was designed with MVC in mind-the platform predates widespread knowledge and acceptance of the MVC pattern in web development.
Droplets are a generalized mechanism for invoking Java code from a JSP (and previously, JHTML) template. The closest analogue in J2EE-land would be tag libraries. So you can use them to accomplish many different tasks. You can also use them as a poor man's MVC controller. This is done by coding a custom droplet class dedicated to handling the business logic of your page, and setting relevant page state as request parameters. Then you invoke the droplet as the first step in your JSP page. This is not very different from J2EE model 2 with the odd quirk that first your compiled JSP begins executing, then invokes your "controller" code and then resumes with processing the "view."
Form handlers, as the name indicates, are designed for processing form submissions. These are executed by a link in the servlet pipeline (DAFDropletEventServlet), before the page which was posted to begins rendering. Typical usage with form handlers is that they will send a redirect after executing, and cancel rendering of the page, which will abort any further processing by the servlet pipeline. Form handlers are the closest thing to a "controller" ATG provides. But they are awful for handling GET requests and result in some very unfortunate URLs when used for this purpose.
Why did they create two different mechanisms? Why have they not subsequently introduced an updated MVC model as part of the platform? These questions I cannot answer.
ATG, at the page rendering level, is not MVC. Don't look at it as MVC. ATG, at its core, is an extension of the basic Servlets API.
Forms and form-processing, with the successUrl and errorUrl is kind-of MVC. Droplets certainly are not.
It is perfectly acceptable in an ATG application to be fetching data as the page is rendering (i.e. Droplets)

A self contained service DLL with Entity Framework

I am looking for some best practice advice with regards to building a self contained service, that is a DLL with all of the domain logic and data layer. I would like to use an off the self CMS, such as orchard, then talk to the service to carry out CRUD operations. The service should have it's own IOC, and ORM, in this case I am using Ninject and Entity Framework. In this design I will have a separate database than the CMS, and can port it to other CMS systems when required.
The CMS should start the service and pass it a connection string or file name. If I use orchard it has different ORM, and IOC frameworks, so this leads me to wanting to keep Ninject and Entity Framework inside the service.
I have setup an experiment where the DbConext and domain are in the service DLL, and I call it from a console app. This only works if I have entity framework referenced in the console application, even though I don't use it in that dll. Here is the error message when EF is not referenced by the console app.
No Entity Framework provider found for 'System.Data.SqlClient' ADO.NET provider.
Why is this and how best to solve my design problem?
If your library (DLL) depends on Entity Framework, it's perfectly normal that you need to reference both in your application (whether it's console, web or whatever else). You always need to reference all dependencies.
Wiring your custom library with Orchard would be fairy simple. The only thing you'd need to do on Orchard side would be to register the services coming from your library with Autofac, in order to have them available for dependency injection. This post describes a similar scenario to yours.
Please bear in mind that using multiple database connections is a bit troublesome in Orchard <= 1.6, because of the usage of TransactionScope - you need to run all your custom database code in a suppressed scope, otherwise you'd have transaction errors and/or MSDTC-related problems. It will be a non-issue since Orchard 1.7 which is going to arrive in about a week. I'd strongly recommend waiting for the new version. You can also fetch the pre-release code from 1.x branch.

Is it possible to use Symfony2 web profiler bundle with Zend Framework 1 or other framework?

I have existing project written in Zend Framework 1, it is long term project, constantly developed and without possibility of migrating to ZF2. It would be really neat to use Symfony2 Web Profiler bundle in it.
Currently, in development, I am using zfdebug (https://packagist.org/packages/spekkionu/zfdebug) which is great, but bundle from Symfony2 has so much more to offer...
I managed to incorporate Composer into my application (in Bootstrap), so loading something with it should be no problem. Also I found package on Packgaist (https://packagist.org/packages/symfony/web-profiler-bundle) but to be honest - I don't know if it is even usable without Symfony2.
Thanks for any tips.
No, this is not possible. If you take a look at the requirements on packagist you see it requires symfony/http-kernel, symfony/routing and symfony/twig-bridge to work. That's because the way the WebProfilerBundle works:
It registers himself at the most common events, the events happening in the HttpKernel and Routing component. If he cannot register to these events, he will not be able to give you timer information.
Moreover, it uses another event to inject imself in your page, meaning that if you don't have that event, you will never see the bar.
And the bundle is using Symfony conventions and techniques, meaning that it cannot run on ZF conventions and techniques. This is why it is called a Bundle instead of a Component, components are stand alone, bundles aren't.

What's wrong with this ASP.net MVC system design?

I have a ASP.Net MVC 3 photo gallery, which is designed in this way:
Data Repositories(IImageRepoSitory, ITagRepository etc)
|
Services (IGalleryService, IWebService etc)
|
Web Application
Which I use Ninject to inject the required Services and repositories into the web application.
Before I use actual database, I used a simple ArrayList (and JSON serialization) as my presistent logic (That will be JsonImageRepository/JSonTagRepository) which works perfectly fine. But later on, I moved to EF4 CTP5 (Code First), and many problems appeared. Basically, I injected those repositories and services as Singleton (which declared in Global.asax.cs), but when I have several threads that access the repositories, it saids:
Data Connection is closed.
I changed to something like Thread Mode or Request Mode in Ninject but various exception raised (regarding to multiple instances of context, so I think Singleton should be the only option).
Is there anything wrong with the design? or how should I configure those components?
Normally, repository access should be in request scope (at least the ones that change data). I recommend looking at bob's blog posts about a repository pattern implementation using Ninject and NHibernate. It should be pretty much the same for EF4:
http://blog.bobcravens.com/2010/06/the-repository-pattern-with-linq-to-fluent-nhibernate-and-mysql/
http://blog.bobcravens.com/2010/07/using-nhibernate-in-asp-net-mvc/
http://blog.bobcravens.com/2010/09/the-repository-pattern-part-2/
I planned adding this to the sample application in near future.

Is ASP.NET MVC a Good Fit for an Event Ticketing Site?

Good Afternoon,
I'm rebuilding an event ticketing site originally developed using ASP.NET 3.5 WebForms and am considering using ASP.NET MVC2 for the rebuilt solution. I like the idea of friendly URLs as the current site has very long query string URLs for each specified event. MVC2 also appeals from a separation of concerns point of view as well. The biggest unknown for me is will MVC2 handle calls to 3 separate web services (SOAP and REST) to get ticket availability? That is, does the controller functionality permit use of such web services? Finally, MVC3 is due to RTM in January. Am I better off waiting for MVC3, or can I start the project in MVC2 and port it later?
Thanks for all your advice and insight.
MVC can handle any HTTP request as ASP.NET forms does. Indeed you should consider to use WCF for handling SOAP queries. And yes, sure you can easely create REST API with MVC.
It is better to start now, with ASP.NET MVC 3 RC2. It is very stable and nice. This will minimize migration work. Welcome to MVC happy world!
The controller will let you run pretty much any code you want.
I just started using MVC in a big project and it's turning out well. We went with MVC 3 and it's been a little tricky living on the edge, but it seems to have a lot of nice improvements. I'm extremely happy to be using MVC instead of Web Forms. To me, it seems to flow smoothly instead of fighting with the way the web works.