Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Note that I am not asking which to choose (MVC or MVP), but rather if one of the two should be used for a web application.
I realize that it might be too much work to convert an older application from its current design to a MVC or MVP pattern. However, what about for a new app? It appears these are the most popular architecture patterns, so should one of these be chosen? If not, what other patterns are there?
If you are not familiar with MVC and/or MVP, a good question to check out is "What are MVP and MVC and what is the difference?". It has many good answers, including links to various websites that break down each one.
MVP / MVC works well in web applications because the HTTP verb + URL combination is a very good way to determine which action to take. There are reasons not to use it, such as if your team has a lot of experience with another framework, but I would generally recommend an MVP / MVC framework. Your application will be finished quicker with higher quality.
Both are great options.
I'd go for MVC as it has a wider adoptions and its easier to understand and use to frontend (HTML / CSS) developers.
Also, given the number of frameworks adopting the MVC pattern, chanches are talking with your coworkers in MVC you will talk a well knew language.
Your question was "should I use one of these design patterns".
I'd have to say that that really depends on the scope of your project. On a very large project that has interdependencies with other systems in a large organization with a large budget, I'd say they are definitely worth considering.
I think these patterns are often over-used on smaller projects where they may add unneeded complexity and cost.
The main point of loose-coupling, is so that you can change your DB or UI at a later time, or re-use business logic. Often times, this never happens. You have to realize that either of these patterns will take longer to implement and complicate the code quite a bit. So, I strongly suggest really thinking this over and weighing your options. You can often deliver a better solution faster by using a very simple architecture that gets the job done and reduces complexity!
I have posted the following answer for another question, though it may be more appropriate here.
MVC is good for plain server side scripting. In MVC developers always try to keep the controller very lean. Mainly controller is for just selecting the appropriate model and reflect on the view. But in today's web applications the View part has radically changed and became complex enough to produce a big, fat and messy controller. So now we need a new place to put the user interface's complex control logic. Here the P of MVP comes in that is the presenter. So presenters are responsible for controlling the logic for a particular user interface component. Don't worry the controller is still here, named as Application Controller. Which ultimately responsible for switching between comparatively larger application components. So MVP can also be said MVPC(!!). BTW this was my way of understanding MVP and obviously not any ground rule.
So I am already tend to MVP for complex web apps.
It depends on the framework you're using. Just use what it supports.
Most web frameworks I've seen use the front controller pattern and call it MVC or MVP.
I think that you should. They are harder to implement, especially in MS world because they did everything to push Web Forms and make building web applications more easily.
Using them you are programming straightforward and you feel like you've done a lot of work. But they are slower and harder to maintain after your site gets bigger.
Using MVC and MVP allows you to separate model(basic classes that represent domain you are working with), controller and views. The best thing about that is that you can reuse your model in other applications like mobile applications or windows apps. They then have more in common than just a database so you have to write less code. You just have to write controllers and views.
I am new to this but I see benefits because when I had to change something on one place something else crashed elsewhere(so you also have to get loose coupling into account and writing unit tests). Writing tests is impossible in Web Forms.
However, if you are building application to represent a person or a company, where there is no business logic on the web, and you have to do it fast, Web Forms are good for it. And also for building prototypes so you can show what application will be able to do when finished.
I like both patterns. My best practice is to choose an pattern, that is always better then NO pattern.
I've developed many applications on both patterns, my personal feeling is that when you are an RAD developer and you are not so good with CSS & javascript(Mostly winforms developers who want's to create an webapp, no offense ;-) ) You should use the MVP pattern because this is very easy to use with the Web Application Projects.
But when you known allot of CSS & javascript then you should consider the ASP.NET MVC pattern.
I would prefer the MVC Pattern, just because the loose coupling. There is a clear seperation between model, view and controller and through the isolation it`s better suited for Test-Driven Development or just Unit-Testing.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
A number of the sites I've recently inherited are in various versions of FW-1 (a "light weight" Model-View-Controller framework for ColdFusion.) I have a functional grasp of it as it is in place, but I'm not seeing the advantages of using it in future development yet.
If you would, please briefly share with me specific experiences in which and how using MVC patterns or frameworks in a database driven web-development environment accelerated the development over what would have been possible in a more linear component function system.
If for moderation purposes only a technical question that can be "answered" is satisfactory, then it is "How does use of MVC patterns or MVC frameworks realistically or in practice accelerate development? (Examples appreciated.)"
I do use FW/1 for almost everything. The balance is done in ancient Fusebox which in some ways like FW/1. For me it has to do with
Encouragement of division of code
After you start doing MVC on any platform, code starts to just naturally divide itself. It is a model, controller, or view? Is this model transient or not? Should the model have a routing pattern? Is this really a view or a layout or a part of a nested layout?
Self documentation
I had over my code to another developer, they instantly know what kind of a thing they are dealing with. It is in certain directory, it has to be a certain kind of thing
Expanded lifecycle
application.cfc has its lifecycle. FW/1 expands it enormously. There are all kinds of places that certain types of code is just supposed to go.
Consistent URLs
The routing patterns defines what kinds of requests will work and which won't. It self-documents the app.
Last but not least
If you don't like all these features, great. Then just tap into the ones you do like. You can ramp up as desired.
I never heard about FW-1, so my answer won't be related with this particular framework. I have experience of CF9 and Railo with ColdBox and Lucee with CFWheels.
All the merits of MVC I found during my work in CFML (I don't want to provide you general answer related with other frameworks I know - Ruby on Rails or Django):
Models are related only with DB staff. Maybe it's funny, but that's how it supposed to be. Sometimes is not. I've seen a lot of legacy code, which meant to be models, but was everything in one place. If business logic in models is isolated from the rest it's easier to test it and maintain it. Also- separated models allows you to use ORM.
Controllers are way much thinner. If you need type less code to do the same job, you'll do it faster.
Templates are only to display what we need, but they don't contain any business logic inside. Keeping it in that manner allows my company to hire front-end engineers, which works on CSS, JS etc. and if they touch CF code, they touch ONLY templates. It would be very difficult for them to deal with all i one applications.
Also I found myself more productive when I know where's find a method which I want to use or simply fixing the bug. If you apply MVC, you can narrow easily possible area of damage when things go wrong and believe- they will.
TL; DR:
MVC makes your development faster, more robust and allows you to split work for different types of developers.
Please help - I'm getting lost!
I'm writing a small desktop application which has some controls and some screen. This should later be integrated with a small web site, also having some screens. The idea is to let the user edit videos and select images, and then share their results with her friends.
The desktop app is using C# WPF, the web site - ASP.Net MVC.
I read that growing the application past a few screens would be easier using MVVM. So I started searching and discovered Caliburn.Micro and MVVM.Light. I have downloaded some tutorials but, just as I was getting ready to deep-dive into the material, I found here on S.O. that there's also Prism, MEF, Unity, ReactiveUI - This is becoming too much!
I'm terrible at learning new things - It's taking me ages to study WPF and ASP.Net MVC. I don't want to study lots of new material only to find out later that it's not relevant. And I don't have an architect to instruct me.
So my question is: Could you put these frameworks and technologies in perspective, and suggest which I should focus on studying and using (esp. what can be later used with Windows 8)?
If you want to build an MVVM application (which you probably do for various advantages), then you want an MVVM framework.
I would recommend Caliburn.Micro, as it is straightforward to implement following the examples on the Caliburn.Micro documentation page. It also has a very compelling convention over configuration mechanism, and uses an Actions system to invoking verbs (methods) on your view models from the view. This is more powerful than any other mechanism I've seen.
Prism is quite a heavyweight framework which includes elements of MVVM design to help the implementation, as well as being particularly tailored towards building composite applications (applications that are built up of decoupled components within a hosting shell).
MEF is useful for these types of applications that need to discover plugins or extensions to the application (even after the application has bootstrapped), and can be used alongside an MVVM framework such as Caliburn.Micro. MEF can also be used for implementing inversion of control, but doesn't provide some of the core features found in other inversion of control containers, so you may decide to only use it to implement plugin functionality.
Unity is an IoC container, and would be used to implement dependency injection for your general application infrastructure. There are lots of IoC containers in the .NET space though, some of which offer either improved performance, additional features, or a more friendly API.
I don't know about ReactiveUI as I haven't used it.
If you're talking about maximising code reuse for a move to WinRT, then MVVM is a great choice.
PRISM already include MEF and MVVM logic :)
Ok little bit of explanation here:
MVVM stand for logic in your application. Actually clever way of decoupling of View, View-Model and Model. Don't know any best (?) framework to do it - you could check Catel if you want or MVVM Light but it just a tons of code from someone who understand the MVVM logic and just make it easy to implement it. You could actually try to write your own MVVM framework and see that 'there's no secret ingredient' - just the same repeating code and same classes, etc... Actually you don't need any MVVM framework to implement MVVM.
Once you learn and write MVVM you immediately run into question - How I NUnit test it in decoupling way (this is not trivial problem in Silverlight for example) - so here all IOC/Inject framework come into play. For example MEF. Consider following example to understand a big picture about Inject framework:
Project 'Shared', written in 'least delimiter' (for example Portable Library)
public interface IAmSharedInterface
{
string SayHello();
}
Project 'Main', reference only 'Shared' project
public class IAmMainClass
{
[ImportingConstructor]
public IAmMainClass(IAmSharedInterface SharedInterface)
{
SharedInterface.SayHello();
}
}
Project 'Implementor', reference only 'Shared' project
[Export(IAmSharedInterface)]
public class IAmImplementor: IAmSharedInterface
{
public string SayHello()
{
return "Hello from implementator class to whoever using it";
}
}
You see - there's no direct reference between 'Main' and 'Implementator' projects - all 'magic' happens in MEF/Unity build/resolve process. So you could easily run NUnit test on Main without using 'Implementor' project and 'Implementor' with 'Main'. There's also a scenario where other project could implement and export 'IAmSharedInterface' specially for testing purposes.
So back to PRISM - it have all (!) this. I know it's not easy framework to understand right away and it doesn't suitable for simple 'Hello World' programs but once you learn it - there's no way back. It just glue all the parts together and give you big degree of freedom in using whatever moq framework you want (for example Rhino).
Prism developing in Microsoft so (I hope) it will be supported not just in Windows 8 but in Windows 9 and in all future versions.
Whatever you asked it's all inside: MVVM, Inject, decouple/plug-ins, easy to read and test
To save adding to the detailed information above, I'll attempt to make life easy for you.
1) For now, forget about IOC / Dependency Injection / Plugin architecture. You say you're creating a simple app, so forget about this for now. Keep your code tidy and you can implement this later if necessary (it's good stuff).
2) Out of the frameworks you've listed I would suggest Caliburn.Micro. It's relatively straight-forward and lightweight. It wouldn't take you long to get up and running.
3) Create your model in a separate assembly which you can use for both your windows app and your MVC website.
Keep it simple and don't get bogged down with all the technologies.
This answer reproduces some abridged chunks of Rockford Lhotka's Blog article "Using the MVVM pattern requires a framework" which was cited in another answer.
It is sort of a meta-answer to this question (though it does contain a specific recommendation), but it seemed very useful to explain the role of a framework in MVVM in the first place.
There are three fairly
popular presentation layer design patterns that I collectively call
the “M” patterns: MVC, MVP, and MVVM. This is because they all have an
“M” standing for “Model”, plus some other constructs.
The thing with all of these “M” patterns is that for typical
developers the patterns are useless without a framework. Using the
patterns without a framework almost always leads to confusion,
complication, high costs, frustration, and ultimately despair.
These are just patterns after all, not implementations. And they are
big, complex patterns that include quite a few concepts that must work
together correctly to enable success.
...
Trying to do something like MVVM without a framework is a huge amount
of work. Tons of duplicate code, reinventing the wheel, and retraining
people to think differently.
At least with a framework you avoid the duplicate code and hopefully
don’t have to reinvent the wheel – allowing you to focus on retraining
people. The retraining part is generally unavoidable, but a framework
provides plumbing code and structure, making the process easier.
You might ask yourself why the MVC pattern only became popular in
ASP.NET a few short years ago...
Strangely, MVC only started to become mainstream in the Microsoft
world when ASP.NET MVC showed up. This is a comprehensive framework
with tooling integrated into Visual Studio. As a result. typical
developers can just build models, views, and controllers. Prior to
that point they also had to build everything the MVC framework does –
which is a lot of code. And not just a lot of code, but code that has
absolutely nothing to do with business value, and only relates to
implementation of the pattern itself.
...
Typical developers really do want to focus on building models, views,
and viewmodels. They don’t want to have to build weak reference based
event routers, navigation models, view abstractions, and all the other
things a framework must do.
...
In the meantime, Caliburn Micro appears to be the best MVVM framework
out there – certainly the most widely used [as of 2012]...
(Text copied inline for preservation reasons.)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm inheriting a bunch of programs at work where the original author used Microsoft Visual Studio's data components (where a dataset, data adaptor, etc) are creating inside the design environment (from the toolbox or using wizards). This yields some semi-tailored (specialized for the data) classes, and also puts the SQL code into designer generated classes.
This is not how I'm used to doing things (I've always preferred to either unambiguously have a dataset, or create my own specialized class to hold the data and hide the complexity of the underlying data layer).
Does anyone have some good insight or links discussing the pros and cons of using Visual Studio data components?
(A side note, the original author also didn't comment very thoroughly and wrote, for my tastes, a bit too much "clever" code that is not easily interpreted, so I'm not inclined to think he knows any better than I.)
I suppose another way of asking is this: Does using the data designer components result in code that is "following best practices" and is maintainable, etc? It doesn't seem so to me, but I'm looking for input from experts.
[EDIT: Added some more context for clarification of intent]
If I'm right (and it looks like I am) about using designer components really being best suited for prototypes, etc, then I'm going to have to go have some tough conversations with the original developers and my manager. So I'd like to add more emphasis on "links discussing pros and cons" part of my question... I'm looking for something substantial I can use to support my claims that this style of development / code isn't the most appropriate for production use... Thanks.
In general visual components are for throwaway applications, POC's and spike applications, i.e. prototyping. This is for a couple of reasons; they are very quick to get together but a complete nightmare to maintain. I'm unsure of the size of your application but if it were me I would be arguing that in it's current form the cost of ownership will increase with time and therefore would look to more of a DDD style of development. Bin the data layer and replace it with a good solid ORM; NHibernate(preferred) or Entity Framework 4 (easier to get into). Drop that 'clever code' and start using the Kiss, Yagni, dry mantra. It might be difficult to get them to see the light but once it starts costing less they'll love you for it ;)
If you want some more reading in this area look at the following:
Skill Matter are a training facility that run open session and loads of podcast you can watch
A good book for both Dev's and managers to read is Ship IT, it looks at good project practices. As does anything on the pragmatic bookshelf
Martin Fowlers' blog for all thing DDD
Ayende's blog is great place for all things NHibernate
stackoverflow.com, this place rocks
VS data components purpose is rapid application development. From this point of view you can see its pros and cons:
pros: fast development, do not require much coding and knowledge. Good for small applications which will not be changed in a future.
cons: breaks Layer application design logic (add here all pros of such design) combining all in one file.
As a result almost impossible to replace datasource dynamically. Makes more complicated large application support. DI, TDD - it something mysterious using it.
Actually it's a very wide question.
I'd recommend to read more about N-tier application development and Test Driven Development
Hope this help
I wouldn't even go so far as to say that the designer DB components are good for POCs or prototyping. Those components are in Visual Studio primarily as a sales pitch for the framework, so that Microsoft can say "wow, look how easy it is to create a data-driven application with .NET!" They should have been removed years ago, IMHO.
However, don't confuse the designer components with ADO.NET (i.e. DataTables, DataSets, DataReaders, DataAdapters etc.) itself. Since the app you've inherited was built around the designer components, that means that it was also fundamentally built around the ADO.NET components. You can (and should) get rid of the designer components, but you shouldn't necessarily get rid of ADO.NET as well.
I personally think you are definitely on the right track, BUT imho it really depends on what you already have and what the plans are for the future of the product.
I have seen production code that uses just as you are talking about and works fine, and is somewhat easily maintainable.
There are even some great drop in modules from very large companies such as Telerik that fall into the same category of development that you are talking about.
I think what really is an important factor to your employer is: what can you use to get the job done in the fastest most efficient way. I would say that in general though, the "drag and drop" tools straight out of the box are not very good for long term enterprise level applications.
Here is an article by Charles Petzold that may provide more "expert" credential information for you.
http://www.charlespetzold.com/etc/DoesVisualStudioRotTheMind.html
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I work in a company where, since I arrived, I had full freedom to use whatever Microsoft technology, pattern and tool in order to develop my applications.
I started to develop all the applications with ASP.NET MVC3 and I currently have 5 applications deployed and working.
The other day I had a meeting with my manager to review all the applications and he realized that my code was completely different than what he expected. He basically realized that I do not use Web Forms and that I use MVC instead. He thought he was just some component/tool and not a totally different approach to programming. He was curious and he briefly studied what ASP.NET MVC was.
After two days he said that I need to convert all the applications to Web Forms and use just Web Forms from now on. He says that MVC resembles the old asp(that for certain aspects is true) and that it takes longer time to develop the application and makes people confused when there is the need to change/maintain the application.
I think it is not true because, after a steep beginning, I got used to the magic of MVC and it eases development, componentization and maintenance of applications.
I said him that Web Forms is too coupled UI/Logic/DAL, after a while the code becomes unreadable and it jeopardizes unit testing. I also shown the possibility to replace the old GridView(one of his main concerns) with the jQuery or MVCContrib grids.
There was no way to convince him. Both for work and personal development I do not want to take a step back to Web Forms, therefore I kindly ask you to tell me the most important points that make MVC "superior" to Web Forms.
Thanks
Unfortunately, it's not uncommon for a manager to give a business-speak-laden version of "I don't understand this, so I want you to do it my way instead." This often stifles progress. (I've actually left jobs in the past for this very reason, managers who refused to allow any development that they personally didn't design.)
However, you also need to keep an open mind on the subject. He may very well have good reasons for this. Supporting the code is a big concern, and while I agree that it's easier to write clean and de-coupled code in MVC, at the same time he might be seeing a market where it's much easier/cheaper to hire farmed out developers at low cost to support a WebForms application. He may have a stack of resumes in his drawer that paint a very different picture between WebForms and MVC.
The best thing you can do, really, is approach both paradigms with a completely open mind. Understand that the rumors of WebForms' demise are greatly exaggerated. So if you really want to convince him of anything, then you're going to have to present a proper and unbiased comparison.
Start with a simple pros and cons list to compare the two paradigms. Make sure you don't skip on anything. If he has pros for WebForms and cons for MVC that you tried to ignore, that'll hurt your case. Evolve that list into some examples, demonstrations, proofs of concepts, etc. Make your argument tactile, give it numbers and tangible values that mean something real to management beyond just "this is a better development strategy." Quantify it.
If you approach this with an argument that says little more than "well, my way is better because it just is" then you're not going to get far. Even if you have a point to make, you have to successfully make that point to him. You have to put it in his language.
This is really less about which development strategy is better and more about communication and clarifying your ideas. After all, if you can't defend your position then from his perspective it's not a good position.
And if you fully clarify and quantify all of this, and it's critical that you keep an open mind about WebForms, then what you've done is given him the information he needs to make an informed decision. That decision may not change. He may still insist on WebForms. But it's his decision. What you're doing here is presenting him with all the pros and cons, all the costs and benefits (both immediate and long-term in terms of re-writing what you already have and ongoing support and all of that). If his decision turns out to be wrong, at least it will have been his informed decision. You won't have kept anything from him.
In the end, he may still insist that you do things the way he understands them. Some managers are like that. But take this as an opportunity for your career to master the art of presenting an argument. It won't be the last time you find yourself doing this.
I would search data or survey result showing superiority of MVC projects rather than telling him how good MVC is. MVC is just more productive way of creating & maintaining quality software. One thing I would like to add is that since UI is completely decoupled with biz logic, it is a lot better to automate code production with code generation tools such as T4 and MVCScaffolding.
WebForms was created to make it easy for WinForms developers to move to web. ASP.Net MVC's main benefits are that it separates out the Model (data), View (HTML,CSS,jQuery) and Controller (logic and routing). This allows different people to work on different parts if needed (separation of concerns). It also is much closer to a true web model, designing using HTML directly rather than this being abstracted away by ASP.Net User Controls. Obviously, in MVC, you have the HTML helpers and can make your own custom helper extensions as well as using DisplayFor and EditorFor templates.
The bosses argument is that many developers will know ASP.Net but not MVC, so it will be easier for others to work on it. However, MVC has been out a while now and many keen developers will have already picked this up or can do very quickly. It's a very clean and powerful way to develop web applications very quickly and easily maintainable in my opinion. ASP.Net of course has its advantages too but you asked "what makes MVC superior" so I've just argued a few benefits of MVC over ASP.Net. This is by no means an exhaustive comparison and hopefully others will add their opinions too.
I made some GUI desktop applications on my first years of development, but my experience and practice have changed, so now I'd like to retake this subject with better knowledge.
Most of my experience has been web since then.
I've been reading about GUI Architectures, and several related questions here on S.O.. I know I'm still not in the "architect" level of knowledge from Design patterns and such, as to start building a great GUI App from scratch
I'm trying to figure out how to design an app with a GUI, using good design practices for the architecture. I'm focusing on MVC architectures, with RIAs (Flex, Java FX, you choose), thinking of keeping the GUI as decoupled as possible from the domain. This has brought me some trouble...
I've been having a hard time relating an MVC architecture such as SpringMVC with a GUI, which could also implement its own MVC. Most of what I've read are high level concepts, but I can't seem to be able to translate this into code.
"Where do I create the view?", "How do you hook the controller with the model and the view?", etc. These are some of the questions I keep asking myself after some reading and studying.
I'm probably kind of lost, and quite entangled as to where to start, so any help is appreciated.
Are there any guides/tutorials/documentation you can recommend to start on this subject? I should probably start with the RIA/GUI basics, and then specialize on the technology I'll use.
You didn't specify which language you prefer, but here are some practical guides for Java:
Java SE Application Design With MVC:
http://www.oracle.com/technetwork/articles/javase/mvc-136693.html
Model-View-Controller (MVC) Structure
http://leepoint.net/notes-java/GUI/structure/40mvc.html
Also, for specifically SpringMVC, here are some practical guides:
http://maestric.com/doc/java/spring
http://www.zabada.com/tutorials/spring-mvc-basics.php