So we have a very large ASP.NET WebForms applications (Recently updated to .NET 4.0), and I want to attempt to put MVC in alongside it.
I've read lots of articles around the fact that the 2 types of applications do sit well beside each other. However, the current site makes heavy use of Spring.NET.
Ideally, all I want to do is start adding MVC pages to it, utilising the existing configuration of the business logic.
I've tried just using the MvcContextHandler, however, this leads to errors (The virtual path '/currentcontext.dummy' maps to another application, which is not allowed.) so I'm thinking that it's not as easy as that.
The reason I want to utilise the existing objects is that these will contain context information about the user, and what they've previously selected in the flow, so utilising the existing class that have been instantiated would be very useful.
So does anyone know if this is possible, and if so, are there any resources around to show how to do it?
I'm currently thinking that chaining IoC containers might be an option, so resolving controllers using Ninject, so the parameters are mapped to get the dependencies from the Spring container, but that seems like a long way around...
We upgraded a medium LOB-app to MVC3/Spring.Net and retained the analytics part written in Asp.Net WebForms (Telerik controls, reporting services), so it is possible.
Imho I did not use the MVC3 support facilities brought with Spring.Net and instead wrote a new one. At that time MVC3 was quite new the documentation that ultimately helped was:
http://bradwilson.typepad.com/blog/2010/10/service-location-pt5-idependencyresolver.html
According to Brad, to implement a dependency resolver for MVC, you will need to implement this interface:
public interface IDependencyResolver {
object GetService(Type serviceType);
IEnumerable<object> GetServices(Type serviceType);
}
http://msdn.microsoft.com/en-us/library/system.web.mvc.idependencyresolver.aspx
Related
Recently I started working on a new project using .NET Core 2.1 and I decided to use the SOLID principles and create a nice project structure.
It is a Web API project. Everything is working fine I use a lot dependency injection, most of the stuff is easy to test.
And that's the part where I have to register all my services. I am literally having hundreds of lines looking like this:
services.AddSingleton<...>();
or
services.AddScoped<...>();
I have one line for every service and for a small project it would be fine. However when I have hundreds of these it becomes on BIG mess. Basically the whole project is in a super nice order and there comes the Startup.cs that is full of services.AddX statements.
I was think of creating static classes with methods that register the services but that just doesn't look fine.
I will need to add more services in future and I can't just keep creating static classes or filling the old ones because I will end up with the same mess again and it will be more difficult for me to remember where am I registering a given service.
If you really have hundreds of them, you may want to replace the default container with for example Autofac. These type of frameworks supports modules or kind of "subcontainers".
A module is a small class that can be used to bundle up a set of related components behind a ‘facade’ to simplify configuration and deployment.
Replace DI
Autofac modules
You can have each logical group of services (assemly) export its own RegisterServices method. It is the responsibility of that assembly to select lifetime and scope anyway.
For cosmetics, make it an AddMyStuff() extension method in the Microsoft.Extensions.DependencyInjection namespace.
See AddMvc() for an example. Look it up (F12) and notice the difference between the assembly and the namespace it is in.
What architecture and patterns can I use to share the most model and logic code between a WPF and an ASP.NET MVC application?
I am trying to achieve a bit more here than just separating my data entities from the two presentation projects. There is a lot more in common e.g. UI logic on what gets displayed under what conditions, when is something required, etc. that I would like to keep in the shared code.
ADDED: I am just beginning to really like the concept of view models independent of my entity model driving my presentation. While some of the annotations used in these are located in assemblies specific to MVC, none of the metadata provided is actually web specific. I would very much like to explore using my MVC view models as data sources for binding to WPF views. Any suggestions on this front will be most appreciated.
My personal favorite configuration is similar to the one Adam King suggested above but I like to keep the logic DLL as part of the web project. I run a project called CT Terminal that follows this pattern. My Terminal.Domain project contains all the application logic and simply returns a CommandResult object with properties that act as instructions to tell the UI project what to do. The UI is completely dumb and only processes what it's told to by the Domain project.
Now, following Adam King's approach I would then slap that Domain DLL into a WPF app and then code the UI to follow the instructions in my returned CommandResult object. However, I prefer a different approach. I wrote the MVC 3 UI to expose a JSON API. This API can be consumed by any application. The JSON API was simple because it was basically a wrapper around my Terminal.Domain project CommandResult object. The JSON returned would have the same basic properties. In this way I would write the WPF app to consume this API rather than the DLL. Now if I make minor changes to internal application logic I just deploy the Web project to the live server. All clients using the API automatically get this new logic.
Obviously if the changes being made affect the properties being returned from the API then that would require a release of new client code, but at least for internal logic you wouldn't have to do that.
One of the most widely used patterns seems to be having the Entities in a seperate DLL assembly, then having this referenced from each of the other projects.
MVC 3 suits the repository pattern very nicely, which can be a clean route to take in the first instance, and will work for both WPF and ASP.net
I actually found Rocky Lhotka's books, software, and videos on this topic very helpful. Here's a few links to his content:
http://www.lhotka.net/
http://channel9.msdn.com/Events/Speakers/Rockford-Lhotka
http://www.amazon.com/Expert-C-2008-Business-Objects/dp/1430210192/ref=sr_1_2?s=books&ie=UTF8&qid=1331834548&sr=1-2
Create a service layer for your application by specifying interfaces with methods that represent all of the operations you need to perform. Also, in this service layer, define all of the data types used by the application. Those data type classes should contain only properties, not operations. Put these interfaces and classes in an assembly all by itself. This assembly should be shared between your web app, WPF app, and the code that implements it.
Finally once you have this separation, you can freely develop the application's internal structure, and leave the responsibility of UI operations (e.g. what happens when you click xyz button) to the respective UI.
As an aside, you can expose your service layer, via WCF and web services. You can use this to make call from the web browser via javascript. You could do things like client-side validation or even look up values on the fly for drop down population. all while reusing it between your two application.
Starting with the obvious. Encapsulate your business logic and domain model in a separate assembly.
In terms of Presentation Layers and shared UI Behaviour, the closest you will get is the MVVM design paradigm, implementation will be C# in WPF/XAML and Javascript for your ASP.NET MVC web frontend.
For the web frontend you can get close to the WPF (MVVM) way of doing things with http://knockoutjs.com/ written by Steve Sanderson of Microsoft. Its MVVM for the browser. Also checkout http://www.asp.net/mvc/mvc4 for more info.
Use Web Api, let both the WPF and the Web application consume the services from Web Api.
Done.
Did you try using Portable class libraries. With this you can make the data layer and use it in ASP.Net MVC, WPF, Windows Phone, Silverlight.
Think at this scenario:
I have a c# windows form application. This application was the same for all my customers. Now one of them needs to modify a form adding new textbox and new logic.
I obviously don't wanto to duplicate my application, and inserting IF statements with customer-Id to control the logic can easly drive to a spaghetti-style code.
I think that in this situation I can create a separate dll project for each customer; Inside I can write custom forms implements same interface as default form (and same for logic classes) and I can try to switch those dll via configuration file or build the project with the right customer dll (or using, for example, Windsor Castle for DI).
Is this a valid pattern? Exists a different way?
update
I try to list:
MEF
Autofac
Windsor
Castle
I think in this case, MEF would be a better choice. Castle is more like a DI engine for business logic, useful for controlling the object life cycle, especially when you want to be able to switch the way the program works (multiple small threads or one single large operation in one thread).
MEF, on the other hand, strips you of the need to add a config file for this type of configuration. You just operate with libraries. I think MEF is best for client-side GUI forms.
If you are developing a multitenant application, there are DI frameworks like Autofac which support this kind of customization. Take a look at this article
You can also use your Source Control system to help you out. When you need to customize, create a branch and do the customization there so you do not have to duplicate your code.
I'm currently working on a large real-time OLAP application. All data are hold in RAM (a few gigabytes) and the common tasks involve brute scanning over the large quantity of that data (which is fine). The results of processing are exposed via a Web service (singleton/multithreaded) and presented using Silverlight-based client.
The problem is that various customers need different functionality/algorithms and I don't know how to provide extensibility on the server-side. For the client side (Silverlight) I can use MEF/Prism, but I'm not sure what would be a good approach to tackle this problem on the server.
Please note that ideally other web-services should have a direct access (i.e. without marshaling) to the data of the main/current service which holds the large data model.
Are there any:
a) frameworks/libraries
b) patterns
c) good pracitces
which would help me to modularize the application and make the selection of desired modules and their deployment relatively easy?
Sounds to me like Dependency Inversion is required: isolate logical parts of the system (algorithms, etc) by defining interfaces, then use a DI / IoC framework to load the desired implementation at runtime (or on application start, etc).
I haven't used Ninject, but plenty of people love it, so you could try that; there's also Spring.Net.
Good Practices:
Ensure you have clear precise logging so you know what's being used and when.
Think about whether you want a 'default' implementation to load if the desired one fails, or whether you deliberately want to fail so that the wrong data isn't returned by mistake (such as the use of a different algorythm).
I've found that using attributes to decorate injectable modules is really helpful (especially in a web-based system that you don't have immeadiate access to) one reason for this is that you can build pages or controls that list all the known / available implementations at runtime.
You can also use the attribute approach to build a UI that lets users select which one they want; I use it for an open source web-application framework I built: http://www.morphological.geek.nz/Morphfolia/Capabilities/AttributeDriven.aspx
I've written a program using Domain Driven Design in .NET 2.0 and I'm trying to implement a plugin framework for it.
I've implemented several types of plugins:
Domain Plugin
A domain aggregate composed of one or more domain classes
One or more View/Presenter pairs to display instances of the aggregate
An import/export service specific to the domain aggregate
A repository class
Service Plugins
Database Plugin (embedded or remote)
General import/export services (cvs, xml, competitor's data formats, etc)
As you can see, some plugins touch every layer of architecture. You could say that the domain plugins are miniature applications that simply depend on the main application to provide a framework in which to run. The ultimate goal is to let the user purchase and download only the plugins they need. I wrote them as static dependencies at first because I hadn't implemented a mechanism to load them dynamically. Now I'm trying to tackle the dynamic loading.
I'm trying to use an IoC container to manage the dependencies but I'm having difficulty working out how to find and load the plugins. In addition to the interfaces each plugin exposes to the main application, classes with each plugin also have their own interfaces they use to communicate with each other.
I'm using Castle Windsor as my IoC container and would like to take advantage of its autowiring capabilities both in the application and within each plugin as well.
How do I:
Find and load into Windsor implementations of a specific interface
Ensure Windsor resolves the correct one
If you think I'm going about this the wrong way feel free to say so. I still have time to change the design before my deadline.
I'm note sure I've understood you completly but consider looking at MEF (http://mef.codeplex.com/)
You could use something like the Managed Extensibility Framework to discover and enumerate your plugins at runtime. The plugins could then register the necessary types with your IoC container when they are discovered.