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.
We have project developed in Silverlight/DevForce services, currently we plain to move code into HTML5. My question is it possible to reuse server side part of project, I means is it possible to reuse DevForce services or better migrate to WebAPI services? IdeaBlade has Breeze Js for HTML5, but it looks more as dataservice provider and not support DevForce services.
You might be asking whether BreezeJS offers a mechanism for handling arbitrary service calls between the client and the Web API running on the server ... in the manner of the DevForce "invokeServerMethod".
BreezeJS does not . The DevForce "invokeServerMethod" is helpful when you need to talk to the server for non-data reasons. You don't have to open and secure your own channel; instead you can share the DevForce secure data channel between client and server. It's also a convenient way to sent a package of entities. Setting up your own independent channel is not much fun.
But writing and communicating with a Web API service endpoint is much easier. Our thought is that you can manage your non-data communications quite well without the help of the BreezeJS EntityManager. So we don't see the need to implement the equivalent of "invokeServerMethod"
However, perhaps you have a scenario that would cause us to reconsider. We'd love to learn more.
Breeze doesn't integrate with DevForce today. I'd recommend adding the request to the Breeze UserVoice site. The Breeze team uses UserVoice to judge interest when incorporating new features.
A quick look shows me that there is already one DevForce related suggestion there: Support for DevForce models.
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
Just started with NServiceBus and I am trying to understand how the bus fits into my VS solution.
Let's assume an existing application, that has an ASP.Net front end and a BLL. I am using Windsor for DI and my BLL has no knowledge of the container. I wire the container up in a separate project I call "MyNamespace.IOC", and only this project and my web project have knowledge of Windsor.
I need access to the bus in my BLL (since that is where I will be sending/publishing/handling messages). I need to configure NSB using Windsor, and (I think) pass an instance of my container to the Configure.With().CastleWindorBuilder() method at app startup.
It seems odd to have all three projects have reference to the NSB DLLs. How does one normally wire this all together?
If you do not want to reference NSB in your BLL / domain layer you could have a look at 'domain events'. The domain event handlers can sit in their own implementation layer leaving your domain ignorant of the handling of the events and, therefore, requiring no knowledge of the service bus. From there you could publish your esb messages. It may not seem like much of a difference but the domain event-handling layer is more isolated from the domain.
Just as a side-note: since you are starting out with a service bus you could also have a look at my FOSS project over at http://shuttle.codeplex.com/ --- any feedback would be appreciated :)
You can abstract bus behind some interface and provide the implementation only in IoC and Web projects.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I need some resources that talk about how to design your software to be extensible, i.e. so that other people can write add-ons/plug-ins that adds functionality to it.
What do you recommend? Any books out there that discuss the subject?
I would prefer something that's short and to the point; a bit of theory and a bunch of concrete examples.
I'm not targeting a specific language, I want to be able to understand the core idea so that I can implement it in any language.
And for the same reason, I prefer not to do it using a framework that someone else built (unless the framework is not very high-level, i.e. doesn't hide too much), at the moment I only want to educate myself on the subject and experiment with various ways to implement it. Plus, a framework usually assumes user's knowledge about the subject.
UPDATE
I'm not asking about OOP or allowing my classes to be inherited. I'm talking about designing an application that will be deployed on a system, such that it can be extended by third-party add-ons AFTER its been deployed.
For example, Notepad++ has a plug-in architecture where you can place a .dll file in the plugins folder, and it adds functionality to the application that wasn't there, such as color-picking, or snippet insertion, or many other things (a wide range of functionality).
IF we're talking .NET, try Scripting .NET applications with VBScript over on CodeProject. Lots of concrete examples there.
Below are sites implementing various application extension techniques
ClearScript - Makes V8, VBScript and JScript available to .NET apps
CS-Script - The C# Script Engine
Plugin Architecture using C#
Opinio plugin architecture
Notes on the Eclipse Plug-in Architecture
Plug-in Architecture Framework for Beginners
Gecko plugin architecture
Fungimol plugin architecture
OSGI is a good practical example of a technical framework allowing to do what you are after.
The theory is here.
The (free!) book is there.
Extensibility and the ability to write plugin must deal with service lifecycle
adding / removing service/plugin on the spot
managing dependencies between services
managing states of services (declared, installed, started, stopped,...)
What is OSGI for ?
One of the main functions of a module is as a unit of deployment… something that we can either build or download and install to extend the functionality of our application.
You will find a good introduction here, on the central notion of service (which is related to your question, and which explain some problems around services, key component for extensibility).
Extract:
Why are services then so important if so many applications can be built without them? Well, services are the best known way to decouple software components from each other.
One of the most important aspects of services is that they significantly minimize class loading problems because they work with instances of objects, not with class names. Instances that are created by the provider, not the consumer. The reduction of the complexity is quite surprising
Not only do services minimize configuration, they also significantly reduce the number of shared packages.
Implement SOLID principles in your application.
1. Single responsibility principle: A class should have only a single responsibility (i.e. only one potential change in the software's specification should be able to affect the specification of the class
2.Open/closed principle: Software entities … should be open for extension, but closed for modification
3. Liskov substitution principle: Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program
4. Interface segregation principle: Many client-specific interfaces are better than one general-purpose interface
5. Dependency inversion principle: One should Depend upon Abstractions. Do not depend upon concretions
Stackoverflow questions:
Example of Single Responsibility Principle
Is the Open/Closed Principle a good idea?
What is the Liskov Substitution Principle?
Interface Segregation Principle- Program to an interface
What is the Dependency Inversion Principle and why is it important?
You try to reach two competing goals:
The components of your software must expose a lot of themselves, so they can be reused
The components of your software must expose very little of themselves, so they can be reused
Explanation: To encourage code reuse, you should be able to extend existing classes and call their methods. This isn't possible when the methods are declared "private" and the classes are "final" (and can't be extended). So to meet this goal, everything should be public and accessible. No private data or methods.
When you release the second version of your software, you will find that many of the ideas of version 1 were plain wrong. You need to change many interfaces or your code, method names, delete methods, break the API. If you do this, many people will turn away. So in order to be able to evolve your software, the components must not expose anything that is not absolutely necessary - at the cost of code reuse.
Example: I wanted to observe the position of the cursor (caret) in an SWT StyledText. The caret is not meant to be extended. If you do it, you'll find that the code contains checks like "is this class in the package org.eclipse.swt" and a lot of methods are private and final and whatnot. I had to copy about 28 classes out of SWT into my project just to implement this feature because everything is locked down.
SWT is a nice framework to use and hell to extend.
Of course there is the famous Open Closed Principle - http://en.wikipedia.org/wiki/Open/closed_principle
Well it depends on the language.
In C/C++ I'm pretty sure there is a loadlibrary function that allows you to open a library at runtime and invoke it's exported functions. This is typically how it's done in C/C++.
In .NET, there is Reflection, which is offers similar (but more broad) to loadlibrary. There is also entire libraries built on Reflection like Managed Extension Framework, or Mono.Addins that does most of the heavy lifting for you already.
In Java, there is also Reflection. And there is the JPF (Java Plugin Framework) which is used in stuff like Eclipse IIRC.
Depending on what language you use I could recommend some tutorial/books. I hope this was helpful.
Plugin architecture is becoming very popular for its extensibility and thus flexibility.
For c++, Apache httpd server is actually plugin based, but a concept of module is used instead. Most of apache features are implemented as modules, like cache, rewrite, load balancing, and even threading model. It is a very modular software I ever saw.
And for java, Eclipse is definitely plugin based. The core of Eclipse is an OSGI module system which manage bundles, another concept for plugin. Bundle can provide extension points on which we can build modules with less efforts. The most intricate thing in OSGI is its dynamic characteristic, which means bundles can be installed or uninstalled at runtime. No stop-the-world syndrome any more!
Since I dont have enough rep points to leave a comment, I am posting this as an answer. SharpDevelop is an IDE for developing applications in C#/VB.NET/Boo. It has a pretty impressive architecture that allows itself to be extended in a number of ways - right from new menu items to development support for whole new languages.
It uses a bit of XML configuration to act as a glue layer between a core of the IDE and the plugin implementation. It handles locating, loading and versioning of plugins out of the box. Deploying new plugins is matter of simply copying in the new xml configuration file and the required assemblies (DLLs) and restarting the application. You can read more on this in the book "Dissecting a csharp application" by the original author(s) - Christian Holm, Mike Krüger, Bernhard Spuida of the application from here. The book doesnt seem to be available on that site, but i found a copy that might still be around here
Also found a related question here
Checkout "CAB" - Microsoft's Composition Application Building blocks Framework. I think they've got a "web version" of that too...
I have just started to develop a smart client application. These are two options I am considering.
Using Microsoft's System.AddIn namespace. Looks very promising, however it may be a little complex for our end solution.
Or the Smart Client - Composite UI Application Block from Microsoft
Recently, i have looked at taking components both the Composite UI Application Block and the System.AddIn namespace to build my own. Since source code is available for the CAB it is easy to extend. I think our end solution will be a light weight version of the CAB, definatly using the Unity Application Block
If you work with .Net, our research yielded two approaches: scripting and composition.
Scripting
You extend the functionality of what your classes can do by orchestrating them using scripts. That means exposing what is compiled in your favorite .Net language in a dynamic language.
Some options we found worth exploring:
IronPython
IronRuby
JavaScript: Jint, Jurassic and JavaScript .Net are good starting points.
Script.Net -> this one was the first one to call our attention.
Composition
If you start a project with .Net 4 or above, you must take a good look at the Managed Extensibility Framework (MEF). It allows you to extend the functionality of your apps in a plugin way.
The Managed Extensibility Framework (MEF) is a composition layer for
.NET that improves the flexibility, maintainability and testability of
large applications. MEF can be used for third-party plugin
extensibility, or it can bring the benefits of a loosely-coupled
plugin-like architecture to regular applications.
Managed Add-in Framework is also a good read.
MSDN: http://msdn.microsoft.com/en-us/library/dd460648.aspx
Codeplex: http://mef.codeplex.com/
Rather than re-inventing the wheel, use the frameworks in hand. Eclipse and Netbeans both support plugin based extensions. You have to work in Java though.