I am refactoring some code and am working with another programmer. I suggested refactoring the code to follow the MVC pattern to remove all the plumbing from the forms code and put them into seperate classes such as a controller and model class for database. He disagreed with me saying that VB is not meant for MVC and that we should put the code into DLL's. I agree with DLL's but put the MVC into the DLL's is my opinion. Have I got the wrong idea ?
It is a desktop application? because in that case it would be more useful a pattern of MVVC. In any case, I recommend that you seek information from Domain Driven Development (DDD). Here's an article from a practical example =>http://www.codeproject.com/Articles/768664/Introduction-to-ASP-NET-Boilerplate
Related
I am working on a silverlight project and I am using MEF to download xap file of other silverlight project and use its pages and functions in my main Project.
I can do the same thing using referencing dll of that project into my main project.
So I want to know what is the difference between using MEF to reusing components and Simply Adding Reference to the DLL of another project in current project? I mean that we also add reference to the project we import in our current project. Then how it is different from conventional form of component use?
Thanks,
First, we need to separate MEF and PRISM (since you used it in your tags).
MEF is primarily used to provide inversion of control (IoC). It makes it easy to manage dependencies your viewmodels and other classes to separate concerns and improve testability (amongst other benefits).
PRISM however is primarily designed for the following scenario: You don't know, what view goes into a specific container at compile time, and want ViewA for CustomerA, ViewB for CustomerB and so on. PRISM helps you to losely couple your regions and views in a way, so that the application can decide at runtime, what view will be displayed. Another scenario, is that administrators get one view, other users another etc. PRISM also has other features (like the event aggregator), but I'd say the former is the most important one.
Now, I'd say MEF is never a bad thing to use for a bigger project. But I'd only use PRISM, if you really need the functionality it provides, since it can be very limiting. If you don't, simply add the references as you explained and let MEF know about those assemblies with the AssemblyCatalog.
So for MEF, I'd suggest you learn about Depdendency Injection and IoC. I found this blogpost by Martin Fowler quite good. As for PRISM, get familiar with what it does, and decide if you really need it.
Hope this helps.
Let me complement Lue's answer on the difference between MEF and referencing dlls a bit:
The two things are orthogonal activities, meaning that if you reference a dll directly you might still want to use MEF to detect the types in it - and vice versa you might grab a specific type in a dll you dynamically loaded directly (without MEF).
MEF basically finds types in dlls according to certain criteria and has a bit of convenience stuff in it to automatically populate properties and collections with such types. It can be used to make a system more decoupled and thus more maintainable. For example, a video editing software may look for all types implementing a certain interface in all known dlls to use as filters. Whether you include the filters directly as a dll or let the user download them on demand: In both cases your application becomes slightly cleaner by using MEF, since there is no hard-coded list of filters anywhere. Still, in the presence of dynamic library loading MEF is especially useful.
I am trying to implement a global exception handler in Asp.NET MVC 4 beta. As I understand it I am supposed to implement an IExceptionFilter and add that to the filters collection. However I was unable to make it work when using the System.Web.Mvc.IExceptionFilter. Am I supposed to use that one, or is the System.Web.Http.Filters.IExceptionFilter (and related classes) the ones I should be using?
Asking another way:
Should I be adding filters to the GlobalConfiguration.Configuration.Filters or GlobalFilters.Filters?
System.Web.Http namespace completely belongs to ASP.NET Web API framework, not ASP.NET MVC.
As for the registration point, you need to add them into GlobalFilters.Filters collection.
So after getting some pointers from #tugberk, I realize my mistake. I was basically asking for the wrong thing. What I wanted was to be able to add filters for an ASP.NET Web API service, not add them for an mvc application.
I made this error thinking they were one and the same. I guess I must have read som of what was said about moving these things together the wrong way.
In any case. I should be using the System.Web.Http namespace for my case, which means adding to the GlobalConfiguration.Configuration.Filters collection.
I found a rather nice weblog showing a basic implementation of some of what I want to accomplish. Maybe it can help somebody else.
I have planned to write my own light weight MVC for PHP, that will be used as base for my sites I develop. I have no problem with PHP, OOP, et al. I have trouble on how to actually load Models In controllers and use them amd loading Controller values into Views. In short, I don't know how M-V-C interact behind the scenes.
Any tutorial (concentrating on that) or any contribution is welcomed!
Thanks!
ASP.NET MVC is open source: http://aspnet.codeplex.com/releases/view/58781
Edit: consider this: I believe you are trying to reinvent the wheel, thinking that those MVC framework out there are heavy and packed with uncessary features (acording to your double use of the word lightweigth). In my experience, I always ended up coding those extra "features" because a framework is required to evolve. Loading models In controllers, using them and loading controller values into views is just the begining. If you want to get started eventually, it would be a better investment to write some helper classes and methods: a popular pattern in the MVC world. Unless you are writing a MVC framework from scratch for fun and I am totally wrong (you said you needed a base to use for your sites ).
Best of luck!
Codeigniter is an open source MVC framework of php.
http://codeigniter.com/user_guide/overview/appflow.html
The major in MVC is first of all your controller class initiated and then calls view.
After google and check how other MVC works I decided to take this route. I redirect all my requests with .htaccess to index.php. Then there I define base paths. After all the definitions I include the core.php which in turn includes all core files to my mvc framework. Then in the same file I create Instances of Registry and router and the game starts from here!
Internals are a bit complex now but that is what I ended with!
I have been using NHibernate for a few years, but whenever I have a question I find myself in the situation of "it would take me 8h to build a sample app/adapt my business-code before I can ask a question".
Is there a simple Visual Studio project out there (maybe even including something like "AbstractDomainObject") to download which one can reference?
Cheers, Patrick
Sharp Architecture is a good place to start as it "provides a solid architectural foundation for rapidly building maintainable web applications leveraging the ASP.NET MVC framework with NHibernate." The Sharp Architecture zip files can be found at GitHub.
Another possibility would be use to the .NET Reference App which is used in Headspring's Agile Boot Camp training.
Finally, the example source code provided with ASP.NET MVC in Action could also be useful.
I own a copy of vb2005 professional.
I need to migrate a vb6 project to vb.net
Is there any difference in terms of effort to migrating to these
editions of vb.net
thanks
I think it's slightly easier to target the later versions. I believe the PowerPack 3.0 was added for Visual Studio 2005: it included extra support for emulating the VB6 Printer object and shape controls.
Anyone who's read my other answers about VB6 migration should stop reading now because I've said this before... but I think it's relevant, so I'll say it again anyway.
Check out the Microsoft UK advice with a screencast explaining the 5 basic options for .Net migration. Decide which is best. People may advise you to just rewrite from scratch in .Net. Be cautious about this - you say your codebase is big, which is a danger sign for rewriting. Microsoft UK say
Performing a complete rewrite to .NET is far more costly and difficult to do well [than converting] ... we would only recommend this approach for a small number of situations.
I'm rewriting a lot of VB6 currently and what I've found so far is that the previous developers had to use a lot of third party and custom modules to implement what they need when a lot of it has been included in the base class library for .Net since then.
From what I've seen there's no easy way to migrate from one to another. A lot of effort goes into these migrations. The best thing to consider is whether you want to try to go line by line or examine the code, document core functionality, evaluate how well the software has worked over it's lifetime and then engineer a new design.
That's what I've ended up doing because a line for line rewrite is nearly impossible and a large pain. Compiling libraries and modules into COM to bring the functionality into .Net applications is a lot of effort and kind of a "McGyver" approach. That's why I just documented everything well, understood the process, then wrote as .Net software.
Specifically, what functionality are you trying to maintain? Have you written in .Net before?
In my experience the "migrate" is really a rewrite so it doesn't make any difference what version of Visual Studio you use. I'd use the latest.