I'm creating a new MVC web application. I've never used MVC before (in asp.net). Anyway, in my last project, I used Code First and Entity Framework to handle my data and I enjoyed using that so I wanted to use it again.
Now, in the last project, I had a separate project/folder for handling the models and contexts, and I just referenced it into my main project. Would doing something like that still be the right choice in an MVC project, or should I just run it from the 'Models' section?
This is the website where I was learning how to implement this:
http://www.codeproject.com/Articles/468777/Code-First-with-Entity-Framework-5-using-MVC4-and
Is there anything wrong with that approach or is it fine?
Nothing wrong.
If your project is not big enough go for it. Having just one project make it simpler though that you must keep the code organized
If your project might get large, then it would be a good choice to have two project or more for different layers and tiers of your application, such that different guys work on their own project.
Related
I wanted to build a VB.net web application using MS Visual Studio 2015. Someone suggested me to create a Web API instead of MVC project if i'm also planning to create a mobile app later on. I may use angularjs in my project so controllers will surely be used, so what should i choose when creating the project in the first place?
Because when i created a web project: File=>New Project=>ASP.net Web Application=>Empty..there are no folders for Controllers, Model, etc. Do i have to create a Controller folder on my own?
Or should i do this: File=>New Project=>ASP.net Web Application=>Web API..? sorry if its a silly question. its just that i'm afraid that if i chose the wrong project now, it'll affect the development later on.
Answer to your question mainly depends on your choice and needs,
for example
In Case of an empty project as name defines you will have nothing else web.config.
Benefits of it:
here you can define, design your own structure. you can either make
it simple 3 tier or you can make it WEBAPI application. it's all up
to you.
however in the case of choosing Webapi template you will have a prebuilt structure which can help you out for initial understanding
https://docs.asp.net/en/latest/tutorials/first-web-api.html
benefits of it
You will get predefine template and structure.
you can utilize of webapi's which further isolate you backend logic from the frontend.
as you are also planning to create the mobile app. and using front end as angular, so in that case, webapi may come handy.
as the whole world is moving towards webapi, so i will recommend you to use it. please refer https://blogs.msdn.microsoft.com/martinkearn/2015/01/05/introduction-to-rest-and-net-web-api/
so down the line it all depend on you if you want to build you application for the stretch and take full control of it regarding structuring backend etc.. then go with empty else go with Microsoft pre-define template
Thanks,
Ajay Kotnala
Right now I have a single ASP.NET solution with one project in it. The problem I'm facing is that multiple developers are working on different parts of the project that are getting released at different times. Because of this my project manager is thinking we can split the project into multiple dlls instead of just one dll so that we can update just the modules that need to updated.
1. Is splitting the project into multiple projects (multiple dlls) the correct way to solve this problem?
2. If so, how do I do this?
Can I just copy the appropriate aspx/cs files to the new project, remove them from the old one and build? What about Master Pages, CSS, Javascript and User-Controls, will I need to copy those along as well or can they be referenced in the "Core" Project? Would I need to make some adjustments in IIS or can I just copy the aspx from the new "sub-project" to the root of the "Core" Project (essentially where the aspx files are now)?
3. If not, what is the better solution to fix my issue?
Thanks for your help
Edit (to add a bit more clarity):
Right now our structure is something like this (shortened and code-behind implied):
MasterPage.master
styles.css
SplashPage.aspx
Page.aspx
AnotherPage.aspx
a_MasterPage.master
a_Page.aspx
a_AnotherPage.aspx
b_Page.aspx
b_AnotherPage.aspx
b_AlsoAnotherPage.aspx
Can I take all the a_ pages and roll them into one project and all the b_ pages and roll them into another (which would separate the dlls).
If this doesn't make sense please ask and I'll try to explain it better
Yes
How? Don't think in terms of pages, but rather functionality. The best way to handle your issue is to move the business logic out of the ASP.NET experience layer project and put it in class libraries. You can then have different types of developers working on different types of code.
Now, if you truly have different "sites", meaning they serve different purposes, then you may have to move some pages to one and other pages to another. I can't answer whether that is a need or not.
Hopefully, this all makes sense. NOTE: If you code is contained in Page_Load() and event handlers, you are pretty much screwed until you can refactor the code into individual methods.
3.) What about some version control system, wouldn't that serve you better?
Splitting project like this isn't a good idea imo, it would make sense, if you would like to split logical/physical layers of that project (you could have different project for your data access, another for business logic etc.) But splitting to projects, where one contains "welcome.aspx" and second one "contact.aspx".. hmm I would rather use SVN / Git / TFS / Whatever ;)
Normally you split the project according to the function or feature eg. you could split off the data access layer into a different project.
I ussually try to keep my view together and separate the core features, so it would be easy to use the same dll's over different websites.
eg: I have a project with all the methods and a db for user management.
I could deploy this project on a server and reference it in all my websites.
This way users can use the same login over all my websites.
So once you have a core system, everyone can make his own project and just reference the projects needed.
Yes you just move your aspx/c# files to a different project and reference the new project in your existing project.
I do think that every project needs his own masterpage though (last time I checked that is).
I hope this answers you question.
I am trying to think about a web application development framework for our product development. I want to build an ASP.NET application which has many sub-modules in it. My requirements are like:
The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
Each Module should have their own DLLs.
One project should be for the external container of the application (like the framework) and this project should bring all other modules (of type web application) in the solution to the external container. (Some thing like we have Frames in HTML). So we will publish the external container web application only at the end of the day and all other web application projects will be accessed via that.
I would like to have separate DLL for each module so I don't need to fear about the application breaking when I am deploying my single DLL which controls the entire suite.
I am not sure whether my thoughts are in the right direction. The end result I am looking for is a well-maintained, organized, and modular web application suite.
It is ASP.NET web forms, not MVC. I will use VS2010 for development.
What are the best approaches to do this?
Edit:
The term external container means it acts like a master page which has links to various modules and the various modules are not always in the same project. They can be separate project under the same solution. And I am under the impression that, by the end of the day, I will publish that project only and it will bring the various modules to it.
I actually think the best approach would be one that does not over-architect. I'm concerned that it seems you are producing an overall architecture without sufficient reason.
Are these all new modules? Then just start writing the first one. Use best practices that apply to single modules.
Then write the second one. You'll find you want to use things you already wrote in the first module. Great. That's what refactoring is for. Refactor these things out into one or more "library" projects, re-run all your unit tests, then proceed with the second module.
Repeat until all modules are done.
At the end of this process, if you needed the kind of architecture you've outlined, then you'll have it. If you needed less, then you'll have less, and you will not have spent time creating an architecture which is not tied to real-world requirements.
I'm not going to say this is a "best approach" but I would recommend looking over Dot Net Nuke (DNN) to get some ideas. This started as the old "I Buy Spy" starter web project that Microsoft distributed to show ASP.NET projects, and it took off from there.
edit:
1.The application will be a suite of different modules like CRM, Bugtracker, Inventory management, Finance management etc.
You can do this with DNN. They're also called "modules" in DNN and Drupal.
2.Each Module should have their own DLL's.
Yes, this is a good idea. And you'll see this sort of thing in several content management systems like DNN and Drupal. This way not all implementations of the same website need to have all modules installed.
We have a significant website that is used to host a "service as a solution" application that we charge for (if you aren't an actuary or accountant you won't have heard of it). The lead developer for the past couple years used an earlier version of DotNetNuke as a model for how to refactor the parts of the application that he was allowed to change.
Like others have suggested DNN would probably work for what you're trying to do. If you want to completely roll your own naturally I would turn to some sort of combination of a container "Framework" and a bunch of user controls (.ascx). The container could be as simple as a master page with a menu. Depending on how flexible you want your design you can prefabricate many different pages, each hosting a different control (separate dll as you wish). If you want it to be a little more dynamic you can have one content page that will dynamically load at runtime the desired user control into it. Again this is just a general approach, probably a 30000 feet view into how DNN is implemented anyway.
Name the main project after your company/product and keep it short and simple. You will probably need one or two library projects to support it - these will contain everyday, common logic for such things as error reporting, Web utility methods, etc.
Next, pick one of your intended sub-projects (I don't like the term module in this particular context) and add that to your solution. Whether you are reusing an existing project, or preferably starting from scratch, you will eventually have any common logic in this project moved out to your libraries.
Rinse and repeat. Perhaps take a look at something similar like the Sueetie project which includes several sub-projects like CMS, Blog, Calendar, Forum, etc.
The following article is marked as "outdated" on MSDN but I still think you should take a look at it:
Structuring Solutions and Projects
Also, something similar from the Patterns and Practices Group:
Structuring Projects and Solutions in Team Foundation Source Control
Do you have one solution with the web application project, class libraries, database project and tests? Or, do you segment it into multiple solutions? Why?
I'm asking because we're trying to streamline this scenario for Visual Studio 2010 and I'd like to get input from the community on how you'd prefer to work.
I tend (but not always) to have one solution per job, but I import existings projects from other solutions, such as my WebControlLibrary where I keep common user controls and classes, etc.
My actual solution for the job I then tend to break down into the Web Application, Business Logic Layer, Data Access Layer and Entity Layer, i.e.:
Solution
...MyCompany.WebControlLibrary
...Project
...Project.BusinessLogic
...Project.DataAccess
...Project.Entities
...Project.Scripts
...Project.Testing
...Project.Deployment
If a project requires something such as a mobile device, I'll always put that in a new solution, but it may perhaps share some projects of the current solution, i.e.
MobileSolution
...MobileProject
...Project.Entities
...MobileProject.BusinessLogic
The more 'stuff' you have combined, the slower Visual Studios becomes at building. You can obviously stop certain projects building by default, but that's when you have to start creating your own build configurations. If you are going to be creating large applications, I'd suggest breaking down into multiple solutions. I find it much easier to flick between solutions that to keep changing build configurations.
Another option is that when you build your projects you can reference their DLLs. I prefer to import said projects into my solution as you never have to worry about referencing the creating build configuration i.e. selecting the DLL from the Debug or Release folder.
Stand alone libraries can be their own solutions. References for those libraries can be made into the project that you're working with. Related items like the web application, the test setups, and specific libraries such as data access or business rules can be setup as projects within one solution. It really all comes down to how much you want to break things out for resuability.
This depends a little on the job the project performs.
For ease of use it's simple to have a solution that just contains all the projects required. If it's a large solution this can hamper you later on when the IDE starts to get slow and build times rocket through the roof.
Let's say one of the projects is a library used by your company to take card payments and interface with 3d secure. You present you're own GUI page to take the details etc.
If you had numerous sites that all take card payments you would greatly benefit by having this project in a separate solution and referencing the compiled dll. Any changes you require you would need to open up the solution, make the change, build it, go to the solution you're working in and test it. Sounds like a pita and you find it's just simpler to have it all in one big solution. But then if you have this library in every solution and make a generic change to it you need to repeat that change through out.
So you just need to make a decision on wether you're developing a separate project in the same solution or something that might be used elsewhere. If you needed more functionality than the library provides you could implement a partial class in your project and extend the library in that way. Or perhaps a wrapper class will suffice. But then you know you're not affecting the other sites that use this library and you are keeping your solution smaller and more manageable with a smaller memory print during development.
I'm beginning to toy with the new ASP.NET MVC framework, and reading around in some tutorials I saw that in addition to creating the MVC project, theres an option to add a Unit Test project, using the Test framework (which I have) thats basically already set up for MVC testing.
Its supposed to pop up when you create a new MVC project, and look like this -
http://quickstarts.asp.net/previews/mvc/images/mvcCreateUnitTestProject.PNG http://quickstarts.asp.net/previews/mvc/images/mvcCreateUnitTestProject.PNG
But it doesn't, and I'm forced to create the Unit Test project myself by adding it into the solution, which is time consuming and generally annoying to do considering the MVC project structure...
I've looked around the Test framework settings and found no way to make that window appear, or find any option to create an MVC test project.
Any ideas?
Nevermind, reinstalling the MVC framework corrected the problem