I have a Asp.Net WebApi project. I have a created a class library and I have added controllers and models into it.
The project structure is explained in another StackOverflow question.
QUESTION:
Now I need to debug the controllers in the class library.
What is the easiest way to do it?
UPDATE
My question is about debugging a class library in visual studio 2015.
As it's a class library which needs to attached to a process of running WabApi project.
So when I click debug button in VS, the WEBAPI process needs to be started and attached to class library debug session automatically.
In visual studio project properties, there is a debug option to set "Start External Program". How can I associate the WebApi project here?
Or is there any alternative?
First of all, your WEB API project should contain your controllers, not your class library.
The stack overflow you've shown, is a really bad practice, as your WEB API serves as an entry point (PRESENTATION LAYER ) for your application.
You indeed can make a Library 'Models' for your Domain models, but should also make a Library for accessing your database, called the Data Access Layer ( DAL ).
If you want to add some business logic to it, you need a 4th Library called the business layer ( BL ).
So the flow should be like this:
Client <-> Presentation Layer <-> Business Layer <-> Data Access Layer <-> Database.
The PL, BL and DAL can have references to the Model Library. This whole layer thing is called an N Tier Architecture.
You should also take a look at the MVC pattern for your presentation layer.
OK now that the architecture is done, it's very simple to actually debug / test your controllers.
A first option could be to use POSTMAN to send data to you Controllers endpoint, and just add a breakpoint to the controller and debug step by step.
A second option is to use Swagger, which will provide you with a user friendly interface of your controller's endpoints, and also the ability to actually send stuff to it. It will also give you a template JSON of how the message needs to be structured.
More info on the N Tier and MVC
N Tier: https://en.wikipedia.org/wiki/Multitier_architecture
MVC: https://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
Swagger tutorial: https://learn.microsoft.com/en-us/aspnet/core/tutorials/web-api-help-pages-using-swagger
Regards!
I believe the easiest way is creating a console application to host your web api, then you can use a tool like fiddler /postman to send requests to your api.
https://learn.microsoft.com/en-us/aspnet/web-api/overview/older-versions/self-host-a-web-api
Related
I'm migrating a system to its version 2.0.
It's escalating so I want to build a WCF. This is the first time for me working with a WCF so this may be kind of basic, still, any heads up will be very much appreciated.
The existing system consists of a 3 layered proccess.
UI based on WebForms.
Business Layer.
DAL.
For this 2.0 version what I'd like to achieve is to leave webforms behind, moving to a more mvc oriented interface. And, as I've already said, to use some sort of web service to get through in order to connect to my db source.
The question is as follows. I've been investigating and reading about wcf/restful and in the Iservice.cs I can see the interface and the DataContract with its DataMembers. The scratching-head part is that I already have my classes defined on the other layers. So, what is it meant to be done? Should I define my classes inside the WCF one by one aswell? Can't I just reference my DAL/Object Layer and use the resources available there?
Should I add another proyect to the existing VS2010 solution or should I leave the wcf alone?
I'd love to get some input on best practices also, if you may.
If REST is really what you are after, then there are other options for this than just WCF. WCF is generally overkill for most scenarios, so consider looking into:
ASP.NET Web API
ServiceStack
Both options work with ASP.NET MVC and ASP.NET WebForms, although most ASP.NET Web API examples will be used with ASP.NET MVC, which is the scenario you want to use it in it sounds like.
You can treat the ASP.NET Web API or ServiceStack as another layer in your architecture and just reference it like you would the business or data-access layers, as separate projects in your solution.
better way will be, add another separate layer for WCF service give DAL reference to it, at the same time also give DAL reference to BAL. And DON'T give WCF project reference to any one because you want it to be RESTFULL (i.e. to be access only through HTTP, ftp like protocols)
Here Iservice.cs is just interface which exposes methods to the outer world, it depicts what data, in what form and where it will be find. just implement that interface to any repository class in WCF project, which further will get data from DAL for you. Buisness Layer is the Only layer who will talk to Service layer.
Adding DAL reference to BAL is only for the metadata of the entities.
If i was wrong kindly revert me.
I'm working on my first Visual Studio 2010 solution that has multiple projects. I'm finding myself with some project reference confusion.
I'm trying to create an API project that exposes methods to clients. This API references a project containing my business models. I want other projects to be able to reference the API dll and get access to those business models. Currently, in my test project that tests the API, I have to make a reference to both the API project and the business model project separately.
Any thoughts?
If you want to incorporate an N-Tier model into your application by which business models are only exposed to a single layer you are going to have to create methods and objects at the API level which are responsible for interacting with the business layer and then communicate this information back to your tests or to any other project/person that wishes to plug into your API.
If you are trying to create a level of abstraction between your business models and other projects then you definitely don't want to directly expose your business model logic to everything. Kind of defeats the purpose.
The Wikipedia article on multi-tier architecture might prove helpful to you.
Currently, in my test project that tests the API, I have to make a reference to both the API project and the business model project separately
This is normal, you need to reference both if your "API" project exposes Types from your "business model" project.
Im currently working on a project which is based on Onion Architecture . The above image Shows the Solution.
In the Infrastructure We have External Service . But the WebAPI has access only to Core .
But in the Web API project i want to access the some of the models exposed by the external services ?
How can we achieve this without adding reference to Infrastructure in the Web API .
Or we implemented Onion Architecture wrong?
conceptually you are on the right track, but the implementation isn't a hard a fast rule. to start you don't need 5+ projects at most you need 3 (web ui css/js/views, logic/controllers, code, and tests). and really you probably only need 2 (the application, the tests)
the idea of layers is conceptual, not physical. And there is not a hard and fast rule that says the layers must be completely segregated. rather the core focus of the application is what the application does. as you get into the details of how that is implemented you move to the outer layers.
in this instance you need to access data retrieved from an external service. create an abstraction for the external service IExternalServiceAdaptor. The interface may reside in the domain or server layer, but the implementation might reside in an infrastructure or outer layer where the details of how to call the external service are encapsulated within an implementation of IExternalServiceAdaptor.
If you stick with your physical separation you would have an interface in Core and the implementation in Infrstructure.
But in the Web API project i want to access the some of the models exposed by the external services ?
Actually, your WebApi project should only manipulate object defined in your Core project.
As Jason said, calls to any external services should be encapsulated within an implementation of an interface that resides in Core. And this is where models exposed by your external services will be mapped to your Core models.
Have a look at Matt Hidinger's source code on CodePlex here: http://onionarch.codeplex.com/ and check how he deals with this kind of problem, it's pretty straightforward and easy to understand.
I am new to ASP.NET. I have a general idea with ASP.NET on how to create a web application? But Here, I am asking the question because I want to apply best practice for my coding. So, I want to separate conceptual layers, for example, I want to create function which check session on page_load, if its empty than redirect to default page. I can do this by copy-paste to each new page.but I would like to call function rather than doing Copy/Paste.
I am thinking of creating library for Data Access as well as to connect and do data manipulations. Is it possible?
I just found this article from googling : Application Archi...
Can I use this concept?
Correct. For the Data Access Layer, you can create a ClassLibrary Project and add the compiled dll as a reference to your WebApplication project.
Here is a MSDN Link with the steps on how to do this.
NOTE:
But ideally you can have another ClassLibrary Project for Business Logic Layer, where you can reference your Data Access Layer dll; and then you can add the Business Logic Layer dll to your Web Application (it's all about achieving loosely coupled architecture and building scalable software; again this will depend on business needs)
To start with, here is a good read on "Microsoft Application Architecture Guide"
Absolutely. Just create a new Class Library project in Visual Studio and reference it in your ASP.Net project.
Read about
Base Page
Inherit all your pages from this base page. this will help you in having a OOP approach and also save you the trouble of
Copy-Paste
Add Class Library to your solution as shown below. And then you can move your data access & data manipulation code in classes in the class library.
Add a reference of this class library project to your web application. Now you will be able to call the functions that you have defined in your classes in Class Library in your web project.
VS 2010 Adding Class Library ..
Create a base class say 'MyAppPage' and override OnInit event. In the on init event check for the session. If null then redirect to your login page else continue. Make all your pages derived from your base class instead of System.Web.UI.Page. It will be good if you follow this for user controls also. Its always good to have your base class.
What architecture and patterns can I use to share the most model and logic code between a WPF and an ASP.NET MVC application?
I am trying to achieve a bit more here than just separating my data entities from the two presentation projects. There is a lot more in common e.g. UI logic on what gets displayed under what conditions, when is something required, etc. that I would like to keep in the shared code.
ADDED: I am just beginning to really like the concept of view models independent of my entity model driving my presentation. While some of the annotations used in these are located in assemblies specific to MVC, none of the metadata provided is actually web specific. I would very much like to explore using my MVC view models as data sources for binding to WPF views. Any suggestions on this front will be most appreciated.
My personal favorite configuration is similar to the one Adam King suggested above but I like to keep the logic DLL as part of the web project. I run a project called CT Terminal that follows this pattern. My Terminal.Domain project contains all the application logic and simply returns a CommandResult object with properties that act as instructions to tell the UI project what to do. The UI is completely dumb and only processes what it's told to by the Domain project.
Now, following Adam King's approach I would then slap that Domain DLL into a WPF app and then code the UI to follow the instructions in my returned CommandResult object. However, I prefer a different approach. I wrote the MVC 3 UI to expose a JSON API. This API can be consumed by any application. The JSON API was simple because it was basically a wrapper around my Terminal.Domain project CommandResult object. The JSON returned would have the same basic properties. In this way I would write the WPF app to consume this API rather than the DLL. Now if I make minor changes to internal application logic I just deploy the Web project to the live server. All clients using the API automatically get this new logic.
Obviously if the changes being made affect the properties being returned from the API then that would require a release of new client code, but at least for internal logic you wouldn't have to do that.
One of the most widely used patterns seems to be having the Entities in a seperate DLL assembly, then having this referenced from each of the other projects.
MVC 3 suits the repository pattern very nicely, which can be a clean route to take in the first instance, and will work for both WPF and ASP.net
I actually found Rocky Lhotka's books, software, and videos on this topic very helpful. Here's a few links to his content:
http://www.lhotka.net/
http://channel9.msdn.com/Events/Speakers/Rockford-Lhotka
http://www.amazon.com/Expert-C-2008-Business-Objects/dp/1430210192/ref=sr_1_2?s=books&ie=UTF8&qid=1331834548&sr=1-2
Create a service layer for your application by specifying interfaces with methods that represent all of the operations you need to perform. Also, in this service layer, define all of the data types used by the application. Those data type classes should contain only properties, not operations. Put these interfaces and classes in an assembly all by itself. This assembly should be shared between your web app, WPF app, and the code that implements it.
Finally once you have this separation, you can freely develop the application's internal structure, and leave the responsibility of UI operations (e.g. what happens when you click xyz button) to the respective UI.
As an aside, you can expose your service layer, via WCF and web services. You can use this to make call from the web browser via javascript. You could do things like client-side validation or even look up values on the fly for drop down population. all while reusing it between your two application.
Starting with the obvious. Encapsulate your business logic and domain model in a separate assembly.
In terms of Presentation Layers and shared UI Behaviour, the closest you will get is the MVVM design paradigm, implementation will be C# in WPF/XAML and Javascript for your ASP.NET MVC web frontend.
For the web frontend you can get close to the WPF (MVVM) way of doing things with http://knockoutjs.com/ written by Steve Sanderson of Microsoft. Its MVVM for the browser. Also checkout http://www.asp.net/mvc/mvc4 for more info.
Use Web Api, let both the WPF and the Web application consume the services from Web Api.
Done.
Did you try using Portable class libraries. With this you can make the data layer and use it in ASP.Net MVC, WPF, Windows Phone, Silverlight.