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.
Related
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
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 have to build a small app which is basically a wcf API for CRUD operations to a database. I want to create a DAL --> BLL --> Web service layer in that order.
In the DAL I intend to create basic table CRUD operations to the db on a 1 to 1 basis, 1 call one operation on a table.
One of the requirents are that a legacy app which uses this interface needs to have access to the WCF webservices so that each screen will have an associated web service method. i.e. a screen (which the business decide will have 1 single method to serve each screen).
Im wondering should I essentially build these requirements into the BLL, and then just re-expose via the webservices? Or should I create the BLL to do logical business operations and then build a facade over the top which will create the specific (screen to web method call requirment mentioned above) and then re-expose that on the WCF instead?
I dont want to overcomplicate the app but I want it to be extensible obviously.
Any advice much apreciated.
In general, I think it makes sense to keep your BLL clean and usable by everything else that needs it. Then, if you need to support some legacy calls, your idea of a facade is a good one. That would allow your BLL to stay the way it should, while the facade would orchestrate the correct/existing BLL logic to serve the legacy app.
It's almost a cheap way out to answer this way. My answer is that I agree with you; build a facade to support the legacy calls and orchestrate the existing BLL API calls. That way your BLL stays clean.
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.
I just referenced my application domain layer dll to the new WCF service that I am creating.
On my initial tests I am able to use and return the objects from my domain layer on the WCF service.
Question that come in my mind is none of my domain claseses have [DataContract] attribute so does this create a limitation or problem for me that I should be aware of? Or any other concerns that I should know when using other class library in a WCF project?
You can either use DataContract or Serializable. If you use serializable you need to reference the dll with the types from both the server and the client. This is Ok when you have control of both, but can be a problem if other people want to access your service.
Take a look at this video for a better way of doing it than standard Visual Studio:
http://www.dnrtv.com/default.aspx?showNum=122
First law of distributed object design : don't distribute your objects.
But if you really want because you create a data oriented application, .NET Ria Services is what you want.