I have both a design question along with an overall question of the way WebAPI works.
We have an Internal Website that houses many applications ( a seperate MVC Area for each application). We then have sectioned out the DAL Logic into libraries that are front ended by Web Service calls. The Models/Repositories will call to CRUD things inside several databases (some internal, some third party). So It looks like this
UI -> Model-> Repository -> WebServices -> DB.
This was originally done because we needed to be able to access multiple data access points and funnel them back to the Internal Website for various applications and it seemed like a good way to abstract out all the logic so that the Web Application only focuses on the View end. This pattern has proven to be good for seperation of concerns, but now we are looking into making this available to more than just .NET applications/clients and that points me to begin to look at WebAPI.
Here are my questions:
My main question is, knowing that the Web Services are all done in WCF ( contract based), how hard would it be to convert this to using WebAPI keeping in mind that we wish to make sure the WebAPI webservice is on a separate server from the UI.
Is there any way to set up WebAPI to have contracts and still use the HTTP verbs?
If i am remotely accessing the WebAPI web service via an MVC application on another server and another solution, is there any way to still get that strongly typed objects that you get when you consume a WCF contract?
What are people's thoughts on this design pattern?
Related
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 5 years ago.
Improve this question
Broad, general question:
We have an app that is quickly approaching legacy status. It has three clients: Windows app, browser (web site) and mobile. The data access layer is convoluted at best and has grown organically over the years.
We want to re-architect the whole thing. The Windows app will go away ('cause who does that any more?) We will only have the browser based website and the mobile app, both of which will consume the (as of today, non-existant) API layer. This API layer will also be partially exposed to third parties should they wish to do their own integrations.
Here's my question:
What does this API layer look like? And by that, I mean... let's start in the Visual Studio solution. Is the API a separate website? So on IIS, will there be two sites... one for the public facing website and another for the API layer?
Or, should the API be a .dll within the main website, and have the endpoint URL's be part of the single website in IIS?
Eventually, we will want to update and publish one w/o impacting the other. I'm just unsure, on a very high level, how to structure the entire thing.
(If it matters: Each client has their own install, either locally on their network, or cloud hosted. All db's are single tenant.)
I would think one single solution with multiple projects.
If you put the API as a different site, you can easily add something like Swagger and Swashbuckle to your API
https://github.com/domaindrivendev/Swashbuckle
This will make documentation easy.
From here you would want to put your business logic (the things that do specific things) in a third project.
From here you have two options. The webpage can consume your own API, or you can reference your business logic project.
API on a different site offers some additional benefit if it is public facing:
Separation of domain
Load balancing and added protection
Resource limiting and throttling without site impact
These kinds of projects are a lot of fun, so consider your options and what will fit best.
I hope this helps!
my preferd way of doing this is with an seperate API project. you publisch the API project to one url and the website to another. this lets you develop both applications with no interferance.
that said, I normaly put the logic of the API in a Service layer (SOA architecture). My api project just pass the input to the sercice layer and response with the service response. this way you can seperate the api between public and private and still contain all the logic in one place.
usally i create a Api wrapper as a seperate project to handle all API calls, so other devs can use the API wrapper (just to make talking to the api more easy for my feelow devs)
I am at the start of a new project but I am not sure about some architectural choices.
I was hoping that you guys could share me your vision on this.
The client wants an internal website to manage their clients, projects, stock/products,…
Next to this they also want a website for their clients where they can view the products and order them. So for the external website only a small part of the db will be queried while the internal website will be much bigger.
At first I was thinking about using a WCF service for all businesslogic and repository.
But now I am not sure since I know that only a small portion of the actual logic will be used for the external part.
Using WCF as an extra layer always brings a shitload of extra work and complexity to the project. Is it better to just reference the business/repository layer in both website projects or make use of webAPI in the external website?
Really I need to hear some other opinions before I decide what to do.
There is nothing inherently wrong with going WCF, business layer assembly, or Web API. All have pluses and minuses.
WCF would make the most sense if you may someday have a many different clients needing access to the data/business logic and these clients may need to communicate differently (i.e. HTTP, MSMQ, full duplex, etc.)
Business Layer assembly would make sense if you are quite sure the data/business logic will not need to be accessed by clients other than the 2 web applications you are developing. That's not to say you're boxed in doing this though either. You could always start here and later remove reference to the assembly, encapsulate access to the assembly within WCF or Web API, and then reference WCF or Web API from web applications.
Web API is a good choice for several reasons. It provides the ability for many different clients access to the data/business logic without all of the overhead that comes with WCF. Additionally, if you have non .NET clients you need not worry about some of the tweaks you would have to potentially make on WCF bindings. You can also take advantage of some of what MVC provides you within the Web API such as model binding and validation.
I've builded an N-Tier application for CRUD operation with 3rd party libraries.
This is my app design packaging:
List item
Core - with domain models and entities.
DataAccessLayer - with 3rd party libs NHibernate and IOC container Ninject
Ui - Wpf app or Asp.net MVC app
Now i want to separate UI from DAL, exposing my CRUD repositories via WCF Tcp services.
This choice was made for client-server design:
Server: WCF -> DAL with all 3rd party softwares for Database Connection (a lot of driver are very bigs and expensive to install in 100+ clients).
Client: My WPF or SilverLight UI.
I've builded MVC and WebForms APP, a lot of people think that this is a better solution!
But with wpf I have many possibilities to play with graphics and development is faster for me.
All my repositories extending an Interface (for Dependency Injection with Ninject) and i want to add this to my WCF services without create others Interfaces. A lot of my repo's function returning list of NHibernate objects, how to add Attribute "DataMember" to a non WCF project?
But my simple question is, "WHAT IS THE BEST WAY OF DOING THIS,maintaining a good design?"
Thanks for patience!
Ideally you want all of your business logic in the WCF service with the UI as dumb as possible. That way you can create any number of User Interfaces (WPF, Silverlight, MVC, iPhone even) and they are all small and simple with all the common logic in the WCF.
You need to keep things as loosely coupled as possible so following on from that you don't want to pass database things to the front end. Instead you want to send POCOs or DTOs to the front-end that do just enough for the job. Avoid sending a whole database item to the front-end because ideally your front-end should have no knowledge of what database is being used or how it is structured.
As far as your UI is concerned ONLY the WCF contract is important and the DTOs etc. The WCF should be split into several different layers (or tiers), this depends on your approach but you could have facade, business logic, data access layers (do some research into what fits your situation best). You might want to use repository pattern etc, etc, but that will be in the WCF service and the UI will have no knowledge of what is happening in this "Black box".
Ultimately what you want is for all the components to fit together with the least amount of "coupling" where you should be able to swap one component out for another without everything else "depending" on it and breaking.
This is a DEEP subject and I have scratched the surface but hopefully get your thoughts on the right track!
I need to write server & client part. I need guidance how to start with WCF web-services.
I need to create WPF application that at the beginning will be simple UI for database tables, but later will consume data from server as WCF services.
I was looking at LightSwitch, but it seems impossible to integrated it later with server part.
In Visual Studio 2010 after I create WPFApplication1 project I have Data Sources docked window.
Then I can add new data source and select services
What kind of WCF services should I create for WPF application?
I would like something like WCF RIA Services / Domain services, but they are only for RIA.
At least no support from Microsoft. What is classic way for creating services for WPF application?
Related questions are :
Hosting WCF Rest Services in WPF Application
Architecting a WPF application with WCF Data Services
How to use WCF RIA SERVICES with WPF application?
WCF, Web services or ADO.NET data services: What shall I use?
I would suggest you to create four projects for that porpouse:
Yourapp.UI (XAML code and ViewModel)
Yourapp.Data (Data Access Layer)
Yourapp.Entities (Definition of your business objects)
Yourapp.Services (Services Layer aka WCF)
Yourapp.Data talks to database and retrieves the desired information.
Yourapp.Services maps and transforms that information into your entities (if the logic involved is too complex, perhaps and aditional business layer would be required).
From Yourapp.UI just need to add a Service Reference and consume it like a IEnumerable<> and make it reusable so VS won't create additional objects but point to your entities.
Yourapp.Entities must be referenced in projects 1,3 and 4. This will make your development easier to test and debugable. Also try to use interfases at the service level so mock testing would be easy to implement.
Hope I was clear enough, I'm kind of tired. If any question aroses, add a comment please. Cheers.
Ok, I know it was more a theory answer rather than a practical one. May I suggest you to check these tutorials? MVVM Tutorials - WCF/WPF They are excellent introduction and happens to use WPF and WCF like you require.
A couple of months ago I found them in youtube and believe me, they cleared out a lot of doubts I had at that moment. Since then it's been a lot easier to master. At the beginning WCF can seem more complicated than what it really is.
Sorry for not extending my answer but I don't have much time at this moment. Hope it make more sense now.
I am having a bit of trouble finding relevant and updated information. A lot of what I find is from 2001/2002, and the majority of it doesn't apply.
Basically, I want to create a server/client application. The server will be run from a single dedicated machine, and I will install the client on numerous other machines (remotes).
What I am not sure on (never used ASP.NET Web Application) is do I need to plan ahead for it, or can it be added on top?
I am assuming I can just create the Server/Client applications in C# NET, then create the ASP.NET Web App later to give a web based front end to the server application. If this is correct, can anyone possibly link me to good resources for this type of information? As I mentioned, everything I have found is either old, or doesn't apply.
Ok I think I get what you're asking even though it's not that clear.
You're looking to build a cliet/server application initially and later to provide similar functionlaity via a web based application. Correct? If so, then:
To some extent you do need to plan and design for it. This is what I recommended: Let's assume you're using a layered architecture for you server side application and these layers are:
1. TCP/IP Interface layer
2. Business layer
3. Data layer
The business layer and data layer will be reused in your ASP.NET application as well. Both these layers MUST be completely agnostic of and TCP/IP and Http stuff.
The TCP/IP interface layer, sort of translates the TPC/IP ness of your server application to pure C# method calls to normal data types and makes calls into your business layer. If you follow this basic design you will be able to reuse your business layer and data layer.
EDIT
ASP.NET applications are assemblies. They run in the process space of another "application" (worker process) that in turn runs in the process space of IIS. But nonetheless, the architecture I mention in my answer will work for you (I do this all the time) if you're careful about your TCP/IP Interface layer being the barrier (and interface) or in order words decoupling your TCP/IP "ness" from your business layer.
For example, an aspx page (or MVC controller or asp.net handler) is an "Http Interface layer". If used correctly, the "page" handles all of the http/html stuff and "converts" all of the messaging into regular C# method calls on the business layer completely decoupling the business layer from any knowledge of ASP.NET, http, sessions and the like. The business layer in fact should have know knowledge or dependency on anything to do with ASP.NET.
So if your TCP/IP service interface layer performance the same function (that is the sole responsibility of Service interface layers) then you're good to go. And when the time comes, you'll slap on an Http Service interface layer to your system (sharing the BL and DAL). Hope that makes sense.
It's very common to have more than one project in an ASP.NET based web site, some of which have really nothing to do with the WEB UI.
A good resource on this will be any beginner's ASP.NET tutorial. (I trust your googling skills :-)).
Just make sure you separate the GUI from the implementation (for example - if you use webForms to test it - make sure you don't rely on any webForms specific implementation).
I really recommend reading a bit about ASP.NET before starting the task, but generally, rest assured your c# projects are "pluggable" to an ASP.NET implementation.
Hope I got the question right..
http://www.asp.net/general/videos
http://msdn.microsoft.com/en-us/library/ms178093(v=VS.90).aspx
You don't have to create any client application, the client is the web browser.