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.
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
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.
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'm starting a new WCF-based project which is composed by an "Engine" and some desktop applications.
But i found it difficult to make my project structure.
Engine (Windows Service, which host WCF Services for Desktop applications access and host all my business logic)
Desktop Application (Only Presentation)
Shared
MyProject.Core (Customers/Customer, Customers/ICustomerService)
Engine
MyProject.Engine (Customers/CustomerService, Customers/ICustomer, Customers/ICustomerRepository)
MyProject.Infrastructure.SqlServer (Customers/Customer (LinqToSql Specific), Customers/CustomerRepository)
WinForm Application
MyProject.Core
MyProject.UI
Am i right ?
If you are doing DDD I find it strange that you have no domain model. You have a so-called engine, which has multiple concerns. It implements your business logic and knows about hosting your business logic as a windows service.
I would propose a project structure as follows:
MyProject.Model: Defines abstract repositories, entities, value objects, services (DDD term) and other domain logic. It has no references to other projects
MyProject.DataAccess: implementation of repositories using linq2sql. Has a reference to MyProject.Model
MyProject.ServiceModel: Contains service contracts and other stuff related exposing your domain model as WCF services. this project would also contain service specific representations of those of your domain objects that the service serves and accepts. The reason for this would be that you should probably not decorate your domain classes with the attributes needed in WCF data contracts. This project references MyProject.Model.
MyProject.Service: Contains app.config for your service and performs dependency injection, through a custom ServiceHost and ServiceHostFactory. It references MyProject.Model MyProject.ServiceModel and MyProject.DataAccess + your favorite DI framework (Windsor Castle for example)
MyProject.PresentationModel: Defines various view models and commands to use in your UI. It has service references to the services exposed by MyProject.Service
MyProject.WinUI: Your WPF app. References MyProject.PresentationModel.
Note that most of what you have probably read in Eric Evans' book about DDD is only concerned with the contents of MyProject.Model. The other projects are making up additional layers not directly addressed in mr. Evans' book.
Remember that by having a clear separation of concerns, and using dependency injection you will end up with code that is easily tested. With the structure I have proposed above, you should be able to test almost everything, since your UI will contain only XAML.
Anyway, this is just my take on it. Please feel free to ask if some of this needs clarification.
Good luck with the project.
/Klaus