I am starting a new project which will need a ASP.NET MVC 2.0 website, a Silverlight section and a Windows Phone 7 UI.
My plan was to use WCF RIA Services to create a set of services which would be used in all different UI projects. With the Silverlight project I would use the standard tool integration, the Windows Phone looks like it may have to be WCF Services exposed by the RIA Domain Services, but I'm not sure about the ASP.NET MVC website.
My initial thoughts I would simple reference the class library containing the Domain Services and use them directly. Could this be considered a viable approach to using RIA Domain Services in a ASP.NET MVC website?
Kind Regards
Michael
I know a long time has passed since this question was asked, but since I had to make such a decision, I might as well document it for the benefit of others.
I work in an environment where lots of legacy and new apps co-exist, with the legacy apps being phased out. So we've had to build interoperability between everything from MS Access, to web service end points in C#, VB, Web Forms, MVC 3, even Flex, Reporting Services...the list goes on.
One of the biggest pain points in a multiple-client scenario is the maintenance of interoperability over time. As data, requirements and delivery mechanisms change, keeping things smooth ends up taking a lot of resources.
My approach has been to create one and only one mechanism for reading a given source of data by defining 1) a model, 2) a serialization/deserialization layer and 3) a service layer. All projects that need to use XY_Data must use the XY_Service to get XY_Objects via the XY_Serializer. Direct db calls or stored procs, etc are allowed in the XY_Application. This allows me to drop in replacement DLLs (versioned) with bug fixes and upgrades without restarting anything. I hardly ever do a full publish.
So yes, what you're suggesting will work. I would recommend only that you rigorously enforce the single-source-of-truth and DRY policies both in your data and your APIs.
Related
I am supporting an ASP.NET app, which is installed on a web server and a VB6 app installed on a different app server. There is code duplication in the VB6 app and the ASP.NET app. I want to use some of the code in the ASP.NET app in VB6. I believe I have three options:
Expose the required functionality in an ASP.NET web service. The VB6 app will consume the web service.
Rewrite a small section of the vb6 app in .NET and extend the asp.net app. This will eliminate some of the code duplication.
Setup a class library for the ASP.NET app. Install the vb6 app on the web server. Expose the required functionality from the class library in a type library.
Which option is best? I believe option 2 is best.
Option 1. That leaves your shared, already-tested code on the most modern platform.
This is very hard to answer, as it varies for each company and each situation.
As a general rule, I'm very much in favor of using web services where possible, especially if multiple applications are using the same logic for the following reasons:
If I have to change the logic, I can do it in one place and fix all apps that depend on it
The same can be said for database connection strings, etc.
A bug fix can also often be fixed in one place.
I've had difficulties with a particular database that I need to deal with, where the vendor's updates tend to break their .NET adapter. Twice I had to modify/recompile a ton of apps to resolve this. Since then, we made it a policy to connect to that DB only via web services, so I'll only need to update one app in the future.
When developing mobile apps, the simple fact that we already had all our code in web services makes it that much easier to write apps that are strictly UI and leaving the business/database access logic as-is in existing web services.
All of those are pretty much "Standard" arguments for the SOA approach.
All things considered, my first recommendation, not knowing your specifics would be option #1.
There is a fourth option - a total rewrite of the VB6 app, if it's feasible, and if you can convince those who control the budgets and time allotment. Even with that, you can use the Service Oriented Architecture and split much of the logic into web services.
Are there any good books or websites on this subject covering subjects like:
different migration scenario's (big bang, module for module, function for function) pros and cons
do's en dont's
tooling
handling customer expectations
We have a rather large winforms based product which we would like to migrate to the web. Migrating in a 'big bang' scenario would probably take at least two years. We're looking for alternative scenario's.
I'm especially looking for ways to handle the inbetween scenario, what options do you have to keep customers happy.
Let them use the windows application at the same time as the new web
application?
Let the windows application use the new features from the web
application via a service interface?
Accept the cost of double maitenance for a while to keep customers happy?
You are more likely be doing a complete rewrite. Because web is conceptually different from windows forms, there would be a lot of changes.
Your best bet is stop new development on windows forms app. Start writing a new app for the new features. Then start moving one isolated feature at a time to web.
You have two options for the UI
webforms - matches closely with windows forms model. If you are
using any 3rd party controls like devexpress, you can find the
equivalents in webforms.
mvc - It is more like re-architecting the whole presentation layer.
If your UI layer is already separated from business layer, then it
would be a good choice to go down the path of MVC. However the
development experience is totally different from doing windows
forms.
State
Maintaining application state is comparatively simple in windows
forms. In webforms you have viewstate to do that for you. But you are going to run in to rude shocks as you run into limitations of viewstate, especially when it gets too large.
In MVC, you are completely responsible for maintaining the state.
New skills
You require new skills to mimic state-full scenarios
Strong understanding of javascript, ajax, at least one javascript
framework like jquery. 3rd party commercial tool kits can ease some
of these pains.
Depending on complexity you might need web application frameworks
like Backbone.js /Knockout
Expectations
It would be very expensive to achieve the same responsiveness as windows app, as you will be messing with multiple technologies. Probably your users are going to hate the new app initially. Having skilled web designers on staff is very important
Based on our own experience with moving applications from desktop to web: carefuly inspect the architecture of your winforms applications and if possible - try to provide a web interface at the service or persistence level so that your windows applications use web services instead of directly talking to the database. Then you can let your users launch desktop modules from the application server using clickonce.
Such approach let us move to web quickly and users got the same GUI and a new way to access the application. In fact, it took like 3 or 4 months to redesign existing applications so that they use web services.
Then, we were replacing modules one by one, implementing them as web applications and maintaining both (clickonce and web) for a short period of time so that users were able to get used to new modules.
The migration of consecutive modules from clickonce to web was prioritized in an obvious way - we've started from modules that were used by most users. In fact, the initial release of the system has only one web forms module ready and remaining modules are being replaced for over 2 years now, one by one.
Can I convert a non-MVC asp.net application to be Azure compatible ? Or If i want to create an Azure web application, should it be MVC one ?
The other answers answered your question about converting your app to MVC for deployment to Azure (you don't need to).
If you're creating a new web application and go with ASP.NET MVC (which I'd recommend), just remember if you go with MVC3, you may have to make some of the MVC3 DLL's CopyLocal for your deployment, as it won't be part of your web role instance. At least that's how I still understand it. The 1.4 SDK of the Azure SDK doesn't have a MVC3 Web Role template yet.
See this post on steps to get your MVC3 app Azure-ready.
Hope this helps.
You may take a look at the following blog post for migrating an existing ASP.NET application to Azure. It should not necessarily be an ASP.NET MVC application. Any ASP.NET application will work.
azure has 2 roles
1. a webrole
2. worker role
web role is nothing but an asp.net app. so no need to convert it into an MVC app just any asp.net thing will do fine
Yes, you can. But you need to be aware of certain limitations too, none of which were mentioned in the answers already given:
Your application should be stateless, unless you are running a single instance (for most apps 99,9% reliability is OK, but there are some where you want 99,95%, so you need at least two instances + it gives you additional benefits of a load balancer, etc.). The reason for this is that if you have more than one instance, the load balancer will deliver the request to a different instance. You can use AppFabric Cache to solve this.
You don't have a file system - this is not entirely true, but in reality you should never rely on having local files. All you image uploads (e.g. user profile pictures) should be uploaded to a blob storage and linked to there. How you do this is another matter, and one that can be approached differently depending on the architecture of your existing application. You can get away with files, by using Azure Drive, but it's slow as hell.
No Event Log / RDP - this is also only partially true, but you should rely on other ways of getting diagnostics information from your role. While you can RDP to your role instance, there are better ways (e.g. Azure Diagnostics storage).
Database should be chosen carefully. Sure, you have SQL Azure available, but it's expensive (1 GB = 10 USD/ month). If you can get away with stuff like Table Storage, you may save on some costs. Again, this depends a lot on the architecture.
As for the second part of your answer. MVC as a pattern is nice. It saves you a lot of time, it's much more adapt for the Web as WebForms ever will be. The event based system was designed for Desktop applications, and it was forced onto the web. However, going to Azure does not imply a requirement to go to MVC. What I suggest you do however, is treat it as a nice jump-start opportunity to look into MVC and see how it could help you write your apps better & faster.
As with any other case involving architecture of apps, it depends. If you used common patterns (e.g. IOC, Repository), you will have a really easy time moving any app to Azure.
Is there a business case for using WCF WITHIN your web application (ASP.NET/SQL Server)?
I'm not talking about a service to be consumed by others, but rather a service to be consumed WITHIN the web app. So far, the only use for web services WITHIN the web app I came up with is when I need to call the database from the client (through AJAX).
Please don't give me the copy/paste lesson on web services, all I'm looking for is a CONCRETE EXAMPLE of WCF benefiting the web application, and NOT the other apps consuming the services.
Quick clarification: by "web application" I mean a self-contained CRM of sorts. It does a lot, but it DOES NOT talk to any external apps/db's, and DOES NOT need to have service points open for other apps to consume.
We have a Windows service that gathers live data from the web. Because the data is ephemeral (it's only really valid for around 3 minutes), there's no point in recording it in a database. To retrieve data, the Windows service offers a (TCP transport) WCF interface which is only exposed to the web-server, from which our web-app requests data.
I think it very much depends on how you define "application".
If you're talking about a single web application then with the exception of provision ajax data as you've already noted I'm struggling to think of a generic reason why you'd want to as a web service (even more so for WCF) is just an exposed API and if you're in the application surely it would be better (in all kinds of senses) to go straight to the API without the additional overhead of wrapping and unwrapping the calls and the data - which is pretty much redundant.
On the other hand if by "application" you mean an assembly of "stuff" that delivers a solution to a set (or even various sets) of end users then yes, of course... there is definitely a case where the flexbility of having components communicate via services outweights the overhead issue. Where it gets grey is if there is an assumption that a single application will (or at least might) later become multiple applications wired together - but if you're not doing it now then you're just causing yourself pain you don't need so shouldn't bother. If you need to split it deal with that as a self contained exercise as and when you need to split it.
One concrete example from my practice: On one web site we use actively tables which are implemented with respect of jqGrid plugin to jQuery. The contain of grids will be loaded per ajax. So the most pages of the web site are very simple and have clear XHTML code. The business logic with the interface to the database is inside of WCF service. Inside of WCF service we get data also from other information stores of the organization. In the same way if one will need later to have an input from our project the WCF service will be perfect.
So the usage of WCF WITHIN in our web application helps to archive clear interface, clear separation business logic from the HTML markup and better testability (with utit tests integrated in Visual Studio).
I have a web application built in the asp.net 2.0 MVC pattern.
Now the clients want to update this application with rich UI experience and the latest .net technologies.
Can anyone suggest whether I should use WPF or Silverlight: which one should I choose to change the application per the client requirement? I should be able to reuse my business layers and data layers, and thus reduce the time of development.
If I should choose one of these, please tell me the reasons and describe the requirements and what other guidelines I should keep in mind.
Thanks in advance
SA
First lets clarify the technologies:
WPF is a desktop technology - although you can run it via a web browser using XBAPs however this is basically just downloads and runs the XPF (so your users need to have everything that WPF needs - Windows, .NET 3.0+ etc..)
Silverlight is a proper web technology - meaning it runs across browsers and OS.
So which can you use:
From Silverlight/WPF you can call to web services meaning you can easily reuse your business layers, although you just may need to wrap them.
I would not recommend a full change though - I would adopt a hybrid approach of using Silverlight + MVC. Swap out the parts of the front end (view) that make sense with Silverlight but keeping the the ASP.NET MVC code. This not only means your change is small (you can test out a single change and get feedback from users such as maybe your user base doesn't have permission to install Silverlight and thus can't use it), and you keep the ability to unit test a large part of your code still.