I'm really really new to programming with an architecture, so I hope someone here can help me.
I have a solution on C# .Net with the next architecture:
Data: Contains the UoW, Repositories, Entity Framework mapping and context.
Design: It'll contain the WPF and Web projects.
Domain: Contains entities that all the other projects will be using.
Service: HERE IS MY PROBLEM!! I have no idea what to do here.
I need to implement a web service that will be consumed by WPF and WEB projects but I don´t know if it really goes here and how it needs to be (Web API or WCF).
A Service in this case is a layer in your application that supports the higher layers with methods to communicate with the underlying layers (Data). You should read up on design patterns in general and in particular Service Pattern and Repository Pattern. You should educate yourself on the differences between WCF and WebAPI where the first is XML based and the latter is a RESTful API that I would recommend from modernity perspective if you can choose what to implement.
Web API.
WCF
Related
I've been reading about the Microservice Architecure and with the limited valuable information available on internet, I believe, I have a fair understanding of it from the theory point of view. I understand that on a high level this architecture suggests to move away from monoliths and have small, independent services. However, all the examples that I see on the internet are suggesting to write loosely coupled windows services (daemons in case of non MS implementations) connected to an ESB. I understand that writing small, loosely coupled web services that adhere to SRP also fits the bill of micro services.
That said, oData.Net services, where all oData controllers (micro services?) are deployed as a monolith, is a clear violation of the Microservices Architecure pattern. Is it a correct statement to make that oData.net is not designed to work as micro services? If your answer is no then please explain with help of a an example. Also, help me understand, how to have the API gateway pattern in the mix.
ODATA do fit micro services. However, micro services are not a good fit for odata. What I mean is that there is really nothing that stops you from exposing OData in a micro service.
However, by doing so you typically expose a large set of the inner data structure in the micro service. That would in turn increase the coupling between different services. By doing so, you make it harder to change a service due to dependencies.
My own personal rule of thumb is to expose as small API as possible from each service. And the data structures that I expose are not the same as the internal ones. They might be flattened or a union between data in different internal entities.
My reasoning is: If you are going to create separate services, try to separate them as much as possible. Else you are just building a monolith that happens to run in a couple of different windows services.
oData is entirely valid as a method for exposing a microservice; exposing a explicit table however isn't microservices. So I don't agree completely with jgauffin. There is no reason why an API cannot be made available using oData. Where I do agree with JGauffin is that an API should have a small, and planar footprint that is decoupled from the detailed data structures of the source or destination. Therefore it is up to the service calling it to transform the API, but means that the generic format of the API can be reused as long as the business need is there, and technical platforms switched as required.
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.
Okay people, here's another one for ya'll:
I'm starting in the n-tier apps world. I've done some reading on the topic and general advice is that n-tier apps' objective is to abstract functionality tween layers. So, based on this, in a n-tiered app the regular model is:
Data Access -> Business Layer -> Presentation
Since I'm a .NET developer, I thought that to enhance integration with multiple client types (Silverlight, Web app or even a WinForms client) I should use WCF (Windows Communication Foundation) as data services at the business layer so clients can communicate to it regardless of its type. Also, I'm a huge fan of NHibernate as a ORM. So my structure goes like this:
Data Access (NHibernate) -> Business Layer (WCF) -> Presentation (WPF, ASP.NET, WinForms
Okay, so that is the setup. I'm a total newbie in this kind of approach, so I thought I could post here requesting for advice on this setup. Also, I'm very confused on how to setup this in a VS solution, I like to separate layers in different projects, but what about abstraction of data objects (like Customer, Order, etc.)? Do I put em in a separate library? And what about WCF? I know is a programmer's sin to transfer the data classes over the wire to the client. What's the professional's way to achieve this?
Thanks, any advice would be very appreciated.
That's pretty much on target. N-Tier is a bit more complex than N-Layer however, and can be contrasted by asking, "Are your layers actually living on separate physical servers?"
Depending on how complex your Business layer is, you might want to abstract it further between a Business and Service layer. Typically those two are tied very closely and live on the same physical server. The service layer often acts as a Facade to your BLL.
If you're Presentation layer is on the same server, than your ASP.NET or WinForms apps might want to communicate with the BLL without going through WCF services.
Read up on Microsoft Patterns & Practices - Application Architecture Guide.
Your Domain objects should live in their own assembly typically your domain model. According to Microsoft Framework Design Guidelines, it's good practice to name your project assemblies accordingly:
[Company].[ProductOrComponent].[...]
I happen to like this format of name-spacing and generally use:
[Company].[Product].[Layer].[SubLayer].[...]
Here is an example solution using solution folders to organize each project:
In this example, I have a BLL and Service layer. The Service layer provides the actual implementation in a WCF Library while the Presentation actually contains the WCF Web application to host the services. It's always good practice to split up implementation from interface.
The /Client folder can be ignored, I just use that as a sample console app for testing. Any Client applications that consume your service should probably have their own solution or you're going to be managing a huge solution.
As for your data object being transferred over the wire... I'm assuming you mean the classes from your ORM. (Domain Model) You're correct its generally considered bad practice. The solution is using Data-Transfer Objects. You can see from the picture I have a .Dto library. If you're able to use tools like AutoMapper, than I'm all for it, however, adding DTO's to your solution brings with it further complexity and maintenance. I believe Dino Esposito wrote a good article on the subject. Will try to find it for you.
Hope this helps.
[EDIT]
I should note, I'm unfamiliar with nHibernate's capabilities. There might be better solutions for using that ORM. I've only worked with Entity Framework.
[EDIT 2]
Check out Dino Esposito's - The Pros and Cons of Data Transfer Objects