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 10 years ago.
I intend to build application with Winform and I would like to use MVP pattern.
Since I have never used MVP pattern before, I am not sure how to structure the new project.
Should I use same convention as in ASP.NET MVC like creating in the project separate folders for Models,Presenters and Views, then maybe using naming convention for Presenter classes so that their name ends with word "Presenter" (the same way the names of controllers in MVC end with "Controller")
Or should I create separate projects for Presenter and Model?
Honestly, this is a very subjective question. The way I am doing this today may not be the way I do this for the next application. It simply works out well for me. Also, what works for me may not be the way anyone else would do it - not that mine is wrong, better, or worse.
Naming conventions will help:
PersonPresenter
PersonViewModel (if data is read/write to data store)
PersonView
IPersonView
Also, I have separated my current solution into 3 projects:
The app itself - the only class in that project is Program.cs
Presentation Models: presenter, view interface, view model (if applicable); all in folders organized by their respective views
Views: a project just for the views
Now, the only piece of the solution that I need to reference for unit testing is the PresentationModels project.
Related
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 9 years ago.
I'm currently developing a web application using ASP.Net MVC 3.
I have this structure in my Solution:
WebApp Project (Models, Views, Controllers)
Service Layer (Interfaces, Business Logics)
Domain Project (Repositories, Interfaces, EF)
EF4POCO Project (POCO)
Just wanna know if it's the correct way, I have my DATA ACCESS LAYER and BUSINESS LOGIC LAYER on separate projects.
As long as your application layers are loosely coupled (e.g. by using interfaces/dependency injection/etc), they could be in the same project.
But yes, splitting them in separate projects is common practice and is likely to be more maintainable and scalable in the long run.
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 9 years ago.
Last time I worked on a sizable project with MVC was version 2 and it was a while ago, so I've been out of the loop. Now I am getting started on a small reporting project.
Basically, there will be a half-dozen pre-canned reports and some with criteria to be selected by the user. The users will access the content from computers and iOS/Android devices.
What are some of the libraries that I should include in the project to get me going fast and provide a quality product?
So far I got ELMAH and MiniProfiler.
My list:
Webapi - Create and use an API for your communication with Android/iOS
NHibernate - ORM - if you think your project requires one
Structuremap - Dependency Injection
Automapper - map domain objects to viewmodels
Squishit - I personally love this library for minification but you can also check out the inbuilt mechanisms
I think mvc dose not have change workflow from first version but I have checklist for project
Use T4MVC for Typed Address
for Test I use NUnit
AutoMapper for mapping viewModel
ELMAH for error handeling
Entityframework
MiniProfiler
Bootstrap or jqueryUi
StructureMapper for DI container
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 10 years ago.
In VS 2010 Web application, I have few design pattern classes Singleton & Factory etc, currently residing in Util Folder. Would it be correct to move them into App_Code folder.
As per the layered architecture what is the recommended place to put them into ?
Thank you for your help.
Different teams have different naming / structure conventions. I have seen Util folder used, Helper folder etc - just check with the team where they would all be happy to house the files.
Also, as you mentioned APP_CODE, are you using Web Project instead of Web Application?
http://msdn.microsoft.com/en-us/library/dd547590.aspx
It's absolutely up to you, or up to the dev-group to decide ho to design layout of these kind of files.
So feel free to pick the most approriate layout for you.
You should structure them in your application as they conform to the model they ultimately represent. There's no pre-defined 'right way' to do it. The system you're modelling is the driving force.
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.
Update: Thanks for closing my question because it might solicit opinions or discussion. That was the point as spelled out by the disclaimer below. Will someone please reopen this?
Disclaimer:
For starters, I realize how this question and possible answer isn't very black and white, but I am at an impasse and I need some different points of view.
Question:
When I am working in WPF, I often use the MVVM pattern to make things happen. In any given program I will have a bunch of View Model classes that all derive from a class called 'ViewModelBase' and it has been my habit to suffix the class names with 'ViewModel' However I am finding that I wind up with a lot of classes that have very long names such as...
InputDataViewModel
CalculationsViewModel
and so on. I like that they have some context in their name, but they can be a bit cumbersome when it comes to generic programming, etc. I am beginning to come to the opinion that the fact that they all derive from 'ViewModelBase' is enough information to identify them as view models and so the suffix on the names is becoming more trouble than it's worth.
Does anyone else have a similar experience or insight to offer on this issue? Pros, cons, etc?
Also:
No, I am not using an MVVM framework like caliburn, MVVMLight or anything like that.
Assuming that you are using a good IDE, like Visual Studio, you really don't need to add ViewModel. This is because Visual Studio's intellisense makes it easy to see what a class derives from, the methods it supports, etc. The benefit of adding the suffix is that people who don't use a fancy IDE will still be able to work with your code.
Also, you might have other classes that involve Calculations. Adding a unique suffix to each class name makes it easier when you or another developer is quickly scanning over your code. Without the suffix, it may require a further lookup in another file to determine what a class does.
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 10 years ago.
Why does MVC work so well in ASP.NET but not in (.NET) winforms?
There isn't an explicit MVC for winforms offered from Microsoft. However, I see people attempting to use one but they are a bit of a mess compared to ASP.NET MVC.
In my opinion it's due to the fact that there is a one-to-one relationship between the request from the browser and the controller that handles it, as well as the model and subsequent view that renders the model.
With Windows Forms, you don't have such a mapping. You can have multiple things that trigger an event, and you can have multiple views on the model. Because there isn't a request-response pipeline like there is in a HTTP request (one request, one response), you have to handle things like registering multiple views (something you don't have to do in ASP.NET MVC, there is one view, the one that is dictated by the controller), as well as multiple ways of indicating the same input on the controller (again, only one way in ASP.NET MVC, and that's through a request, although this is minor compared to the first point).