I am currently developing an application that utlises telerik ORM tools to manage access to a back end database. On top of this layer I am implementing a Business Layer(domain) containing the real world objects that represent my application model.
So far so good.
The issue I have now is one of serious confusion. I will be developing a ASP.Net MVC web site that forms the main hub of my application. In addition to this I have the requirement to create a WPF application that implements some integration into the desktop and lastly I would like to implement a Windows 8 phone app containing a subset of the ASP.Net website functionality but that will also implement some of the WPF functionality.
The problem is I would like to keep the application as simple as possible and maintain a high level of code reuse. Ideally I don't want to implement multiple business layers but I'm not sure of what architectural patterns would be best used? I think adding some kind of service - be it REST, Web services, WEB API or something on top of the business layer and then dealing with each UI technology independently will be the way to go but I thought I'd ask for opinions and advice before I head down a route and end up back tracking?
You could use WCF or Web API as the layer that sits on top of your business layer. If you're looking to use RESTful api, then the new Web API is a good place to start.
If you take a look at these tutorials, they should help: http://www.asp.net/web-api/samples
Your client applications would then call into these API's to communicate with your business / data layer.
Related
I have been wondering whether this combination of technologies would work. I can implement a modular web application with MVC, EF, and utilize AngularJs if I would want to play around with the technology to implement sort of a mini SPA. I would like to extend my knowledge a bit further, and I was wondering whether I could utilize node.js instead of EF for relational database communication. Can I intermingle MVC back end with AngularJs for front end (mixed with MVC), and node.js for database communications
Is it possible? Yes, technically, but it would be very bad practice.
ASP.NET's MVC does nearly everything server-side. This means that views are built within the server and sent to the user. The controller is also server side.
With AngularJS, this paradigm is flipped on its head. The controller and view are both client side. The server sends the user all of the views and controllers at once, and then from then on only serves data. This is very attractive for single-page applications, and sites that want to exchange data, but not have to constantly send a new view. NodeJS is a popular architecture to use for the server, but any server architecture will work fine with Angular.
Both systems have their pros and cons, but there is no sane reason I can think of to use them together. You can certainly use ASP.NET as the server/model for an AngularJS application, but I'd discourage you from using APT.NET MVC with Angular.
I have currently a visual studio that contains 3 projects :
MyApp.Models : Contains all my models with Code-First migrations
MyApp.Web : Contains my main website, only with MVC
MyApp.Pass : Contains a subdomain website, for customers.
We have new projects and we need to have those things :
A WebAPI that can be consumes by my main website, my pass website, a backoffice website, and a mobile application
a backoffice website that consumes WebApi, built with AngularJS
A mobile application that consumes WebApi, built with Xamarin
How can i layer my visual studio solution to only have one WebAPI that can be consume by all my differents websites/mobile app ?
Best regards,
I am currently building a side project - viewingbooker.com which is exactly the setup you are looking for.
What you need to bare in mind is that web api and mvc website have 2 different authentication techniques. Web Api 2 makes amazingly easy to authorise users from eg. xamarin mobile apps. Token is issued and is generally valid for 14 days of inactivity.
I have few projects within my solutions. Most importantly you need a separate project for your business logic. I also use DI to test my business logic as I go.
For website, I serve data as JSON from standard Controllers. For my mobile app, I have a separate web api project that serves the data separately. They both use business logic project so it keeps code redundancy to the minimum.
Remember that mobile app is not a website which you can quickly fix. If you end up using the same models and controllers for website and mobile apps, any change you make will brake your mobile apps and not all users have auto upgrade feature switched on on their mobile devices.
So I recommend you have a standard website with its own models and controllers, which is consumed by angular/knockout etc. Web API 2 project with its own models and controllers. Business logic project in the form of different services accessible by its interfaces so it's easier to test it. And don't get too paranoid with code redundancy that is different controllers, models for website/mobile. This approach will save you a lot of headache in the future - talking from experience.
Right now ,i and my friend looking forward to make a mobile application, which is going to get data from several different sources, analyze it with some kind of algorythm and make the best decision on that. The main problem is - right architecture for that. We consider that mobile application is going to be just a client, representing data placed somewhere on internet (anyway internet is required).
Can u help us with making right choice?
We have some kind of knowledge about client-server architecture with sockets... But this is definetly not we need in this particular situation.
Our thought is to make a web site which is going to generate all the required data.After that implement mobile apps which will represent info from website, using convenient interface. Is it right way?
Yes, that's the way to go.
Now, you have several options within that architecture...
server gets data from several different sources
server might expose some kind of RESTful API to the client apps
clients can be native mobile applications or client might be html5 mobile apps
depending on the nature of the data, you might want to consider some kinds of caching data that you get from 3rd party services/sources
EDIT:
I use ASP WebApi to build REST Api that serves json data to android mobile app.
So, my infrastructure is:
- MS SQL 2012
- ASP MVC 4, WebAPI
- android mobiles (we're targeting mainly Jelly Bean & Kit Kat)
I've built n-layered application with layers (bottom up order):
- DAL (i don't use any ORM framework...i use my own repository that runs stored procedures on SQL server)
Repository that wraps around db DAL and a few Service Agents that gets data from 3rd party services we use
Business layer where i do our business operations
Service layer (for now, it has no special use but afterwards i might need it as my business layer will be consumed from a few clients: WebAPI, web site, windows service...)
WebAPI for REST where mobile client requests end up
I want to know different options available when we are connecting asp.net mvc application to database.
What are pros and cons of each method and what is best method to choose.
In Traditional asp.net web form application i am using DAL approach, which seems to be very useful to me so far even while dealing in shared hosting environment. I want solution which i can apply in shared hosting environment.
Thank you everyone :)
On the website Mikesdotnetting.com, there is an article titled ASP.NET MVC is not all about Linq to SQL. Basically what the article talks about is taking a standard ASP.NET web forms n-layered application and moving it into the world of MVC. The only things that are changed are the actual web forms into views. He leaves much of the application as is, the data access layer, the entity objects, the business rules, etc. From reading the article and seeing what you're asking, I think you can easily use what you know (your DAL) and combine that with MVC.
Good luck on your project, and hope this helps some.
Original Web form based application article:
Building Layered Web Applications with Microsoft ASP.NET 2.0
I use the the following for the data access:
Entity Framework (Code First)
Windsor Container for dependency injection set up with the repository pattern to make my controllers testable without having a database.
Blog post using EF Code First with MVC
Explanation Repository Pattern
Blog post about using MVC3 and Castle Windsor
There are different Ways to Connect to Databases for ASP.NET MVC web application using ENTITY FRAMEWORK :
Code-First
Db-First
Model-First
Code First approach lets you generate databases and datasets automatically .
Use it if you are developing a large Web application and expecting changes of the Models in Future. So you can alter a database after making changes in the Code Accordingly.
Db-First lets you generate models automatically giving good control over Databases. Make sure there is a Database Admin working in the application.
Model-First Approach is not good option as developer would not be having control over both Model and Database.
I am going to develop the 3 tier application using Silverlight + WCF + ORM
Now my question is if I use ORM at database layer then how can I expose the classes at Presentation, Business layer to do Client-Side validation ?
If you used WCF RIA services instead of plain Silverlight WCF, you can attribute the properties of your data objects (in the associated metadata classes RIA creates for you).
This allows you to add basic validation rules, or even custom ones, that runs on both the server and client.
Using WCF RIA Services via a library is the preferred way to organise projects so try this link:
Walkthrough: Creating a RIA Services Class Library
Also:
Using WCF RIA Services
Creating Rich Business Applications using Silverlight 4 and WCF RIA Services
Various Channel 9 Videos
Is is generally a bad idea to expose your business entities directly to the frontend. Not only is what fits your backend layer rarely a good fit for your frontend but you also run the risk of exposing security critical information to the client - which should never be trusted.
An approach that generally worked well for us is developing the Silverlight Frontend using the MVVM pattern and have your WCF Service Layer return DTOs that can be more or less directly mapped to the data requirements of a ViewModel. This also satifies one of the most important rules when developing intranet/internet client server applications and that is to keep roundtrips to a mimimum because a DTO tailored to the needs of a particular viewmodel can include all the relevant information at once.