We have been developing a silverlight app for the last couple of years. We have a large library base and much of it is reused on the ASP.Net MVC version which we have been developing for a month or so. So I created an MVC app and pretty much added the libraries from the Silverlight server app.
I would like to do a demo for the WP7 version of our app and was wondering what is the best way to reuse the libraries we already have? I was told that I could share files but with such a large library based, I do not want to go that way.
Would it be possible to expose the MVC app via WCF and then get access to the data in WP7 where I can then all the XAML views?
I do not have any experience on the architecture of WP7.
TIA
JD
What you could do is have the MVC app expose the data via a Controller (possibly returning it as json) which would be your "api".
WP7 would just need to make a web request to the api you've already made. WebClient should make this quite easy.
This way you wouldn't need to use WCF.
Hope this helps.
Tony
Related
I am going to build an application with two different front-ends.
the first one is a website which I intend to build it with MVC5 and the second one is with Android platform.
Question:
what is the best practice to accomplish this goal?
should I make the WebApi in charge of working with the lower layers of my application and make call to it via Android and HttpClient (for MVC) or just make my website with MVC and find the specific needed APIs to be called by Android platform afterwards?
I feel something wrong with having a facade (MVC controllers) on top of another facade(WebAPI controllers) meanwhile I can not find any better architecture for these kind of software.
If to start with, you keep the classes with the functionality seperate from your MVC or WebAPI controller code, you can share this between the 2. It can be cleaner to put your Application / Business logic in a separate csproj all together, then reference from your MVC and WebAPI. This will also make it easier to test that code.
This then gives you the option of developing your app MVC first, test with users and get feedback (without spending time on APIs etc yet), and then build your API afterwards for android (using the same application code). You could also end up with both running on top of the API, which arguably would be a better long term place to be for maintenance and security. This evolutionary approach will tend to help you avoid over engineering your software.
I am having one client who wanted to have a website along with an app on iPhone and Android too. So, I am worried about how to structure my MVC solution architecture to best suit the requirement and re-use the business logic among all the platform using Web API.
Can any one suggest the architecture in bit detail to prefer in the above mentioned requirement.
I am wondering what is the better way to go. I created a webapi project and am currently working on making my api.
In the future I want a full asp.net mvc 4 website and that could also contain forms to insert data into my database.
I am not sure if I should
a)
Make a new area in my web api project and build my website from there.
b)
Keep it in the same area and just make some new controllers and such in the web api project.
c) add a new asp.net mvc 4 project to my web api solution project.
Definitely two projects. In fact, I'd actually recommend three projects:
MVC website
Class library, for sharing your DAL/Service layers
Web API
Your MVC site shouldn't need to query your Web API, that's just going to create HTTP latency that's unnecessary. Both your MVC site and your Web API, are just "frontends" for your class library. They will both reference the class library and interact with the class library.
A Web API is only necessary if you're trying to provide third-party access or you're interfacing with a project in another language. If everything is .NET then just share the DLLs and call it a day.
K. Scott Allen recently wrote a brilliant post on the Coexistence of ASP.NET MVC and WebAPI it covers the most common scenarios and when it's appropriate to use WebAPI with MVC or when you should just use MVC.
I would use that as your guide pick the solution that best meets your current needs. My advice is to keep it simple and if your requirements are simple then there is no reason not keep WebAPI and MVC in the same project - it works just fine. As your requirements change you can always split them up into different projects or solutions, but by then you will know exactly why you are doing so.
http://odetocode.com/blogs/scott/archive/2013/07/01/on-the-coexistence-of-asp-net-mvc-and-webapi.aspx
absolutely,
go through link http://efmvc.codeplex.com/
which is the best architecture to develop the big apps
may this one is help you...
another BEST one MVC N-Tier architecture
MVC ---------> WEB API (services)------ > here BL | DL(ORM) | DB)
which you create this in same solution and build the app...
Separate projects for the web api and the web interface will help split things up, but it does cause duplications. We went that way recently and it works well, but it caused a few problems.
Arguments for having a single project :
Since we don't have a domain name yet, we have our API on the 8080 port. We could use a directory binding to make the API accessible from a sub-directory of the web interface but we were worried about production only bugs about absolute path resolution.
Many settings are shared between the two projects so we have to copy them in both web.config files.
Arguments for having multiple projects :
They are easier to upgrade since they can have different dependencies and they can be built totally independently. For example, our API project uses a few more recent versions of some dependencies.
It forces you to extract all of your business logic into a separate library and makes it easier to think about both projects as separate sub-systems.
It is easier to setup the web interface to a separate machine if the load is too much. This is a concern for us, but that may not be your case.
If I had to make this decision again, I probably wouldn't bother with separate projects unless the system was extremely complex and I needed the additional structure. An argument can be made for both options, but I think the deployment headache it brings is not worth it.
I have a site that's done using ASP.NET MVC and jQuery. Is it possible to modify my existing project without too much of rework so that it can be used in phonegap to create iphone/android apps?
Here's an approach: move your logic to an MVC WebAPI (or other REST/webservice) project, then convert the MVC site into a simple html/javascript/css/image site (Mobile site). Then refactor your Mobile site to use Ajax/JS to query the WebAPI/Rest services you created. Once you've separated your code this way, you can then package the Mobile site with Phonegap. I'm not sure how much work that will be for you or your project. If you're using a lot of Html Helpers or Razor markup in your views it may be too involved.
The core point of my suggestion here is to separate your mobile UI layer and the backend processing layer so you can only package the Html5/UI/Javascript layer with Phonegap and leave the backend processing on your web server. I don't think I need to explain this, but obviously the app packaged with Phonegap is not going to have the MVC/.Net framework available on the mobile device to render views or execute controllers, etc. By migrating your UI to be simple Html5 and Javascript you can use Ajax/Jquery/Javascript calls against your backend, which you will probably want to host in ASP.Net MVC WebAPI.
Edit: Guess there was some confusion about my suggestion. I'm not saying this is the only way to do go, but this is what I'm familiar with as it's how our team builds our desktop/web + mobile + phonegap + mvc4 + webapi + kendoui application. This pattern works well for us so maybe it'll work for you too, or at least give you some ideas on how to structure your solution. Good luck!
I'm not sure but you need a server to compile the ASP.NET right? so I don't think that will work for you. I think you need to work with AJAX to do your ASP.NET work and separate your ASP.NET code and your HTML-jQuery because Phonegap wants a index.html file. You can store your ASP.NET files at a server tough
The answer to your question really depends on the type of site you are trying to convert. Are you just trying to put a native framework around HTML and get your app into an app store?
If it is is mostly or entirely informational in nature and you have simply used MVC to build brochure-ware type pages then it should be fairly easy to move. This assumes that there is little to no logic other than page to page navigation.
If your site instead pushes a lot of data around that relies on a back-end server you will need to re-architect it to store data locally or pre-fetch it via a manifest. Next you will need to implement a strategy that allows you to push your local data back to the server.
Does you app need to run in a disconnected state?
Phonegap is one of the options if you want to target multiple mobile platforms & may be most widely used. Since you are using jQuery, jQueryMobile will be a least learning-curve path to use. Effort is mostly on the front-end UI and will depend on how many screens you want to design to provide a sub-set or the full set of functionality you already have on the web UI. Most likely you will have to redesign your screens using the jquery-mobile UI widgets documented here. It is also a good way to show it to your customer the initial screen design with navigation.
jquery mobile is great for learning and designing , but it's slow in the web browser control that phone gap runs in .
you'll need a more lightweight framework for this .
you can use an inappbrowser control to show your site in case it's responsive , but you wont have the device camera and contacts and so ...
take a look at : http://docs.phonegap.com/en/3.0.0/cordova_inappbrowser_inappbrowser.md.html#InAppBrowser
Is there any reason that MVC isn't equally useful for desktop apps as for web apps?
What would be required to make an ASP.NET MVC directory tree implementable as a desktop app?
Prism
I've always thought of the term MVC as the same as a n-layer application - so correct me if I'm wrong here folks.
When i develope, I always(unless other instructed) use the following model/structure, also in applications:
GUI(Web, Winform, whatever) ->
Business logic ->
Data layer ->
And also with an underlying "Model"
... Which is a sort of MVC - So yes, it is usefull for desktop apps also. The main advantage with this, is that you can develope web, win and mobile(++) applications based on the same code.
Another thing that could be done, is to create the data/businesslayers as web-services...
I think this aproach would qualify as SOA.
EDIT:
As a note, the four levels of applications are created as seperate projects - and then used as adding reference to either the project, or the DLL, or from the GAC(or wherever you like.....) :) Thus, the need for a directory structure is not needed.
Hmmm... well, your view can be rendered as anything... HTML, XML, etc. So, why not XAML? I wonder if you can get your WPF or Silverlight app to work in the MVC framework this way... that is, not requiring a web server to run.
There is nothing stopping you from using the MVC pattern in a desktop app. In fact, it has been used on the desktop since before there was a web.
See Wikipedia for some examples
MVC just stands for "Model View Controller" which describes the way that concerns are separated from each other using the MVC pattern.
As far as using ASP.NET MVC on the desktop, there are a few problems. For one thing, it relies on HTTP requests and responses. You would need a server layer as part of your application architecture to listen for requests and send responses. Second, ASP.NET MVC views are really just simple HTML text files meant to be interpreted by a web browswer. So, you would need an HTML rendering component as a GUI front-end. You would likely want a CSS rendering engine and a JavaScript interpreter as well.
Basically, all you would be doing is running a dedicated browser as the front-end and a local web server as the back end.
There is really not much need since there are many great MVC frameworks already. There are also closely related patterns like MVP (Model View Presenter) and MVVM (Model-View-View Model). For example, many WPF (Windows Presentation Framework) apps are MVVM.