We are in the process of starting a web version of desktop application developed in Winforms in vs2008 with linq-to-sql.Has anyone ever done such an implementation? What issues you faced when reusing code for web version?
if you partitioned your business logic and data layer into well-separated objects, it works well. But if you have UI logic scattered throughout it's gonna be painful. My advice: separate projects and unit test for UI, Business Objects, Business Logic and Data and use interfaces between each layer. Done it multiple times and it provides the best way . Of course you're already tied into an existing system.
if you design your application with n-tier architecture, thus you must have separated logic and data access and UI layers. with this architecture you don't need that write logic and data access layers. only write a new web ui for this.
Related
We have an application that is heavily used. In this application we have business logic in our viewmodels and in the service layer
Now we need to migrate the app to html because of performance issues, plus considering that Microsoft throw out the support for this technology.
We can't just stop the application for several months to finish it's migration. Our clients needs to use it. My first approach will be to migrate all the business logic to the services, making the app a thin client, so we can later use the services for ayax calls in a new ui, made with html
Do you have any experience with this migrations? What are the pros and cons?
We are currently doing one of these projects
what I would recommend is following
Have all business logic that aren't UI specific or silverlight specific in its own Business Libraries.
Put a service layer WCF or WebAPI (REST) on top of the Business logic so all the business logic can be accessed via different technologies
Use AngularJS or ASP.NET MVC + AngularJS combination so you can keep MV* pattern going and most probably use most of your ViewModel logic with bit change while giving some what similar experience to customers that are used to silverlight UI
1 and 2 was very important in our project because it gave that clean separation and flexibility to expand to any client machine without changing minimum code. Ex: later if we decided to make an Android app you just have to transfer only viewmodel logic without touching your business logic or services.
What is the better framework for development Windows Store application?
I have used http://metroprism.codeplex.com/ but now I want to use Caliburn.Micro or MVVM light for another project.
I have looked through several application examples for these frameworks but they were not complicated enough for me to estimate usage in bigger projects.
These two ones are completely documented but the problem I think is that documentation for winrt mixed with WP7, Silverlight and WPF and I doubt a bit in supporting all features and practices of using exactly for Windows Store application.
Could you give me advice what is the better one? Or what are the good practices in development for Winrt with modularity supporting like in Prism for WPF and Silverlight.
Thanks.
MVVM Light and Caliburn.Micro basically do the same thing but they do it using opposing "philosophies of development" in MVVM.
MVVM Light is a "view first" approach. In this approach the ViewModel is instantiated in by the View. In MVVM Light this is done via something called the ViewModelLocator, a static class that binds a public property directly to the DataContext of the View.
Caliburn.Micro is a "viewmodel first" approach. Here you find that the viewmodel and view are created by an IOC mechanism that binds the two together. You navigate from viewmodel to viewmodel, with the views being generated in response to the navigation to a ViewModel.
They both have different features:
MVVM Light has a really nice messaging system for allowing view models to communicate with each other in a loosely-coupled way.
MVVM Light has a really simple mechanism for injecting design-time data into your views. Basically it swaps out your runtime services with design-time services that feed data to your viewmodels and, in turn your view. This makes design time data really easy to use.
Caliburn.Micro has an amazing data-binding setup, where it handles most of your databinding scaffolding for you. Basically, it maps the names of methods and properties to the names of controls in the view and autowires them. This saves lots of code and is a really, really nice feature.
Caliburn.Micro uses a "Convention over Configuration" mechanism to map views to viewmodels. MainView maps to MainViewModel, etc. This means you've got no configuration, you just need to make sure that you've got your naming conventions sorted out.
I've used both frameworks (Caliburn.Micro for WP7 and MVVM Light for Windows 8 Store Apps) and like them both for different reasons. MVVM Light is easier to start using but Caliburn.Micro is probably more powerful. I've found them both more than adequate for writing moderately complex applications quickly.
Caliburn.Micro gives you clean XAML at the cost of some magic. MVVM Light is a clean and simple framework that is easy to understand and works well. Prism seems to be a bit heavier than MVVM Light and more business app oriented - it does more than just MVVM. There are many things to consider. Choosing what you already know will let you focus on adding features, but learning a new framework can certainly be a good learning experience helpful in future choices - so you could pick something you haven't used before if you want to learn. You could also write your own framework and only include what you need. I usually go somewhere between roll your own and MVVM Light because that is what I know, though if I were to build a bigger enterprise app - Prism might be better suited for the task. I haven't used Caliburn.Micro because the novelty of different MVVM approaches wore off for me and I just want to create apps. With WinRT a roll-your-own-framework approach is easier than with any platform before because the basic project templates already give you some foundations as I wrote in my Minimalistic MVVM blog post. I would recommend that approach if you already tried MVVM and want to use only the pieces you need - the framework will grow with your app. You can just grab pieces of code from other frameworks if you need them or write your own implementations of the patterns you need.
To summarize
If you want to learn - try something you haven't tried before or write your own framework
If you want to create an app quickly and it is not a huge app - use what you know or go minimalistic and don't use anything but what you get from the templates
If you are building a big app with lots of features - consider Prism or rather first think whether Windows Store is the right target platform for you since it seems to be focusing more on simple in and out tablet apps
I'm just in the planning phase of developing my iPhone/iPad/Android app.
Basically the app will query data from remote data sources and store it locally. As data management will be the key feature of this app, so the UI isn't an important factory in this case. I decided to develop a HTML5 and JavaScript-based hybrid application and deploy it with PhoneGap/Cordova.
I'm a .NET developer, I use Visual Studio 11 for web development, so I found the Single Page Application template, which uses Upshot.js by default.
By exploring the alternatives, I've found JayData http://jaydata.org library. It seems to me that it's something similar to upshot.js.
Could you share your opinion, which way should I go to build a cross-platform HTML5 application?
Upshot and JayData looks similar but actually they are quite different, which makes your choice easier. There are things however both provides
Both has pros and cons (as everything in life)
Upshot.js is backed by Microsoft and focuses mainly on oData + Knockoutjs support. It is included in Visual Studio. You can query oData endpoints with it using a procedural query language.Upshot supports read/write operations, and also realtime updates.
JayData supports multiple datasources, among them are oData but also device local webSql as well, plus some other providers too. JayData let's you query oData or webSql on the same with, with sime JavaScript functions, so you dont have to learn sql and oData uri syntax. JayData provide read/write operations but realtime updates require a small user code.
Can anyone recommend the best web-based technology/language for rewriting a ms-access front-end? I've already converted the tables to MySql and moved all the queries into stored-procedures. The language will need to be able to handle multiple result sets.
Also, I need the GUI to be as similar as possible to the current ms-access front-end. So the new language will need to have features including full CRUD, tabbed forms, datasheet style sub-forms, combo-boxes and reports.
I've dabbled a bit with html, css, php, javascript and java but are any of these capable or suitable? I've heard that Ajax or jQuery might be the way to go.
This is a misguided goal.
Web UI uses completely different paradigms because a web front end is stateless, with unbound data, whereas Access apps are stateful and bound. A 1:1 translation will be a disastrous way to implement a UI in the web browser, unless you invest a HUGE amount in AJAX development.
That said, you should look into Access 2010 and Sharepoint Access Services, which allow you to createn Access front end with web forms and web reports that can be run in the web browser unchanged. This would likely be an order of magnitude cheaper than rolling your own AJAX-based replacement.
We are in the process of doing this. In order to keep the "spreadsheet-style forms" that we have with Access, and which include ordering and filtering capabilities as standard on all screens, we took the decision to go for silverlight + Infragistic toolkit on top of it. Up to now, we have already developped a few screens with these tools, and are quite satisfied with the result.
The shop that I am working part time with is new to Microsoft CRM. I just want to survey what projects have developers done to the system to extend its capabilities.
I can break the work I did into four sections:
Tailoring - Simple field level changes. A lot of this is just making sure the fields and language suited the business I was developing for.
Customisation - More complex changes, generally needing JavaScript and maybe ASP.NET. Some examples would be to use an IFrame and pass values to it from a CRM form. The IFrame would then do interesting things like mapping, charting or give you buttons to do other things. For buttons I would often times use JavaScript to replace the outerHTML in the HTML dom of an IFRAME to show a button rather.
Integration - using .NET to connect MSCRM to other systems. Connected it to Great Plains, Speech Server, SCOM (was called MOM back then), custom LOB systems etc... One interesting one I did was to develop a SSIS component that wrote into MSCRM via the web services.
Reporting - Building reports. In reporting services and in Excel. Excel made for great dashboards because of the dynamic update nature of it.
I have a few (war) stories up at http://www.sadev.co.za/taxonomy/term/7 if you are interested.
I (and others) have implemented a LINQ query provider for the web service layer http://www.codeplex.com/LinqtoCRM.
I did some work with CRM 3.0. My work enhanced the program and turned it into a Document Management app, where you could scan and upload documents based on a case, contact, customer, vendor etc. The .NET SDK back then could have used a bit more work, but I hear with newer versions of CRM it has gotten better. CRM allows for attachments but not at all levels, more at the case level.
We extended 3.0 to send text messages rather than email. There are tools available (for 4.0 at least) to do that now, though.
We also extended it to push service appointments through to Exchange, as due to the workforce being mostly mobile they did not have the CRM client for Outlook.
Two other major areas of development not yet mentioned are plugins and custom workflow assemblies.
Plugins allow you to intercept many of the messages that CRM processes to insert custom logic. The possibilities this gives you are endless because you can intercept all kinds of messages including Create, Update, Delete, and even Read!
Custom workflow assemblies are assemblies that you register with CRM that integrate with CRM's workflow UI. Often times, they perform simple tasks that are useful when modifying form data. Other times, they are more complex like sending status reports.
Custom workflow assemblies are always listed beneath the native options. In the screenshot, everything below "Stop Workflow" was added via a custom workflow assembly.