I have to build 3 MVC web applications using Entity Framework (www.company1.com www.company2.com www.company3.com). The websites will all access the same sql server database, but will be slightly different in their own way (appearance, data etc). More than likely all three MVC applications will be hosted on the same server, but binded to different domain names.
Currently in Visual Studio, I have the following structure to my solution
Domain Classes
Data Layer
Services
Repositories
MVC App 1
MVC App 2
MVC App 3
I would have preferred to have used Area's, but I can't because each site has to be assigned it's own different domain name. I guess I am just seeking assurances that architecting my solution this way won't cause any difficulties for me when the applications are published. I am slightly paranoid about the sites sharing the dbContext or something, however, I know that many sound silly.
It would be great if anyone could advice me if this all looks ok, or maybe there is a better way to do what I am asking.
Thanks as ever.
I've done the same thing for the same reason. I have a CMS that must reside at a different host-name. It works fine.
The trick is finding ways of sharing code across the MVC apps. To avoid circular dependencies and such, I created one more MVC app to hold things such as my controller that serves up image files, HTML Helpers that can be re-used, etc.
As long as you have a good way of validating and differentiating the sites in the Datalayer, than you will not have to worry. How are you validating this?
I also would always put simulair code and pages in a main project so you do not copy parts or even whole pages for different sites. (My guess is that you already did so)
Related
Question : Downside of using Web forms and MVC in same sitecore instance.
Current Situation : We have a Sitecore 7.2 instance developed using MVC and Glass Mapper. We want to reuse existing component which is already developed in Web Forms using the same sitecore version that we are currently using. What we have done so far: To achieve this we did a small POC and were able to achieve the same. We referred below link at Git to achieve this POC We found few blogs where people have done this but always say that it may not work all the time (and not highlighted which scenarios they fail). What are the drawbacks or possible difficulties that we could face doing this ?.It will be helpful if you can highlight as For example :Workflow does not work or personalization does not work etc. Thanks
I am currently running a Sitecore 7.2 instance with both WebForms and MVC (we actually went the other way- our old code is Webform and with a recent redeisgn we moved to MVC) and its doable, but kind of messy.
The biggest issues we've run into have been when we want to display webform and mvc content on the same page, or have the two code bases communicate in any way. Attempting to have renderings calling both webform and mvc code on the same page was disaster. Likewise trying to have webform-only pages communicate with mvc-only pages (eg. building out submenues, getting field values, etc).
In a way, what ended up happening with us was we had essentially two sites - the webforms and mvc versions - and the two never really merged well together. Our project plan was to move off of Webforms to full MVC, so we accepted this as a reality. I'm not sure how well a permanent mvc-webform crossover solution would work, to be honest.
We had some good luck using the following resources: https://www.packtpub.com/books/content/mixing-aspnet-webforms-and-aspnet-mvc
http://www.sitecore.net/Learn/Blogs/Technical-Blogs/John-West-Sitecore-Blog/Posts/2012/06/Using-Web-Forms-and-MVC-in-a-Single-Solution-with-the-Sitecore-ASPNET-CMS.aspx
It's been messy for us, lots of time keeping pages and code apart, and we are planning on cutting out webforms completely in the near future and going full-mvc. But running both is very doable.
I wrote a simple web application on ASP.NET MVC3 (for example, app1). And I now want to write a simple CMS for it (for example, app2).
How can I access to folder app1/Content/ from app2, if app2 is an independed application?
In the future I want to copy app2 to one of the folders of app1 (for example, app2 path will be C:/app1/app2/)
Is this approach correct for building sites in ASP.NET MVC3? If not, please, recomend a better approach!
Sorry for my English.
You should use Area not a different project for simple usages. you can find more here
First of all, yes, it's not a very good design choice.
If you need some common stuff between the 2 applications, you can use several approaches, the simpliest that comes to my mind is to define in each application a variable in app settings (inside the web.config) pointing to a folder or URL containing the common stuff and use that.
Same thing if you need to use the same DB from more applications: just use the same connection string.
If you really need to make the 2 apps work together for some reasons, you should make one single app and a viable solution could be to split it using Areas.
I am working on a simple web application that is built with EF 4.1 Code First and MVC3. My Domain Model sits in a project outside the MVC3 project.
I have gotten to the stage where my web application is more or less complete. However right now, my application doesn't have any form of authorization or authentication. So a regular user can get to Actions and Controllers that only an Admin is suppose to have access to.
My question is, how do I get my web application to work with the .NET Membership ? Because I am aware that the .NET Membership has many database tables of its own !
My knowledge is fairly limited, thus any clear, easy to follow responses would be greatly appreciated.
After the Membership is set up, I know my way around applying Authentication and Authorization to Actions and Controllers.
Thank You.
Go into your C:\Windows\Microsoft.NET\Framework\v2.xx or v4.xx\ and execute aspnet_regsql, this will launch a wizard that allows you to choose your database and it will add the stored procs and tables to allow membership to function.
Then you run the ASP.NET configuration wizard (the little toolbox icon at the top of your solution explorer) and then configure your roles and accounts. See this page and skip to the Configuring the website for membership and roles section.
ASP.Net membership is actually kinda interesting and frustrating to an extent. To you run a tool called aspnet_regsql.exe found in your Windows\Microsoft.net\Framework folder which generates all of the necessary tables to get it running. Next move onto your Web.config file. If you started with your basic ASP.NET MVC 3 template then you should have a <connectionStrings> entry under the name "ApplicationServices". Change that to your database connection string. This is what the membership provider uses to hook everything up. If you look through the rest of the config file there should be sections for <authentication>, <membership>, <profile>, and <roleManager>. These deal with the various sections and settings that the ASP.Net user management is broken into.
At this point everything should be hooked up. If you select your project in the solution explorer, a little red hammer icon should appear. This is the ASP.NET configuration manager. You can use this to set up different profiles and manage different users.
Now this stuff won't be connected to your EF4.1 code first stuff at all. Instead, you can interact with your membership provider through static classes Membership and Roles. If you take a look at the AccountController on a default ASP.Net MVC 3 Internet application template it will give you a good idea how it works.
After working with this stuff for several months, I found it much easier to basically write your own. Tying things together eventually becomes a huge pain and there is a whole lot of extras that the membership provider gives you that is unnecessary for small applications.
Here's the situation. We're adding a new application to our suite of webapps based on WebForms and so I felt this would be the perfect time to introduce MVC.
I did all the research about intermingling the two and got the project all set up using an Area that uses MVC routes while the rest of the (visual studio) project runs with web forms the way it's been running.
Master pages were converted to Razor layouts, not too bad because there was only one master page that was shared between every application.
The problem I've run into now is reusing user controls. We have dozens of custom user controls, many of them fairly complex, that are reused throughout all of our applications. Most of them (especially ones that would be difficult to port) do a fair amount with ViewState and postbacks.
If it were just a matter of rewriting these in MVC, the one time cost would be less than ideal but not terrible. But since the existing apps need to be maintained and updated as well, it seems like maintaining 2 versions of the same behaviour using entirely different paradigms would be a huge drain on productivity.
My gut says there isn't really a good solution and we may have to abandon the idea of going to MVC for this project and stick with webforms, but I wanted to see if the SO community has any insight on what to do in this scenario.
If you have the budget to rewrite those server side controls using the MVC paradigm that would be the best way to go. If not, you could still embed them into existing classic WebForms pages and which would communicate with the new MVC application using standard HTTP/HTML techniques: form posts, sending ids through query string parameters, iframes, cookies, HTML 5 storages, etc... One thing's for sure though: try to avoid putting those server side controls in your MVC views. You will end up with some hybrid application that is neither proper ASP.NET MVC nor a proper WebForms which would be a disaster.
Personally I had to do this same migration multiple times and I didn't bother mixing classic WebForms with MVC in the same application using Areas or some other techniques. At the end of the day it might turn into a nightmare trying to make those two exist together. It's always one of the two: I have the budget and I rewrite from scratch properly or I don't have the budget and I do the new stuff properly using ASP.NET MVC and try to interact with the existing application.
I find it easier to simply start a separate MVC application which depending on the interaction I am looking for would use different methods for integrating functionality from the existing WebForms application.
I am not quite familiar with the complexity and details of your scenario so it is difficult to provide an objective answer but the possibility of continuing to write new code based on the existing WebForms server side controls and not doing any MVC at all for this project might also be a good solution. Writing a new application on ASP.NET MVC just for the sake of it might not always be the best choice.
Seems like every project I'm on uses a Model View Controller architecture, and that's how I roll my own projects. Is there an alternative? How else would one create an application that has persistent storage and a user interface?
MVC has been around for a while. It's a time tested and proven pattern. Many frameworks leverage the MVC Pattern. Martin Fowler has deconstructed the MVC into: Supervising Presenter and Passive View.
Architect Christopher Alexander said it best:
Each pattern describes a problem which
occurs over and over again in our
environment and then describes the
core of the solution to that problem,
in such a way that you can use this
solution a million times over, without
ever doing it the same way twice.
I'm not sure why you would want to move from MVC. Is there a problem you are encountering that MVC does not eloquently solve? To give you a better answer we need to know more about your problem domain.
Things to take into account when considering patterns/architecture: If you are building something with a Myspace type architecture you'll need a robust architecture (MVC). If you are creating a simple crud interface via the web - almost anything will do.
For .Net Web forms (I am assuming web, since you didn't say thick or web client) which is not MVC, it was a nightmare maintaining them. Web Forms applications that lived more that a couple years tended to become big balls of mud. Even then developers discovered ways to use MVC with web forms.
Ironically, the lack of MVC architecture in ASP.NET web forms was one of the driving complaints that lead to the development of ASP.Net MVC framework.
From experience if you don't use some MVCesk approach, your solutions become hard to maintain and bloated. These applications will die a slow painful death.
If your solutions are small one-off projects, the by all means throw something together. Heck there are tools that will generate everything from the screens to the data access layer. Whatever works to get the job done.
Classic CRUD apps built using tools like VB6 and Delphi have user interfaces, persistent storage and don't use MVC. Most of them used data aware controls linked directly to database fields
Couple of links comparing various MV* patterns which might be useful:WPF patterns : MVC, MVP or MVVM or…? & MVC, MVP and MVVM
Look into MVP model view presenter.
User interface is View and an application will always have a model and the bridge between the two is Controller. The whole MVC is nothing special as this is how the things will be always.
At the most you can get rid of Controller and have your view talk to your model but you loose the flexibility.
I've developed an alternative to ASP.NET MVC. You get the same loose coupling and separation of concerns but the difference is in how you go about building your projects.
I have a couple of videos on my blog, source code for the framework, a sample project and a few VS.NET add-ins (New Project item, New Builder and New View).
Builder for ASP.NET
Some key differentiating Features are
1. Templates are just html - no code mixed with templates
2. Templates are thus reusable across views and Web site designers can design templates in their design tool of choice
3. Strongly typed code (no ViewData and stuff) so you get intillisense, compile time checking, F12 navigation etc.
4. You build pages as compositions of views rather than an inside-out approach
5. View can be treated as "real" classes.
6. Everything is complied so no run-time compilation
Quite a few other differentiating factors as well.
In theory :
MVC is a proved technology and yada-yada-yada, and it is ideal for websites.
But in a real case:
A serious project that use MVC required a framework, hence you are following a framework with all their limiting and restrictions. So, at this point, the specific implementation of MVC is rule and not a simple "guideline".
Also MVC fail miserably for websites when it is about to connect to the model other than simple POST/GET, it fail with xml asynchronism and it fail with ajax. (*)
(*) exist some patch but a design must be clear and functional and if you need to "patch it" then it is neither clear nor functional.
Personally i think that the main problem with MVC is that it put so much effort in the Controller, where most project use not more that 5 lines for the controller part.
ps: Most "well done" MVC projects are 3-tier project.
ps2: MVC excluding some framework, is just a buzzterm, IS NOT A SERIOUS TERMINOLOGY and it is reflexed in the group of "interpretation of mvc".