i am trying to tidy up my code, i have a number of projects that have References to my Service Layer i.e the DLL. What this means is that when i distribute a new service layer i have to upload a number of service layers which are generally the same..
Of course using the ADD Reference is very fast as its one assembly talking to another...
I wanted to know the pros and cons of an alternative method..
I could use a web service/wcf to wrap my service layer but isn't this defeating the object..
And what about speed, now my desktop applications need to call to web service/wcf instead of accessing the assembly reference??
My service layer talks to my data layer of course and my clients nevere talk to the data layer directly..
Its the issue of the service layer which is where my business logic is which is shared amongst a number of apps..
Desktop app, 2 x website, 2 x wcf projects(used as web services)
Any advice on how i can achieve the fastest possibly scenerio without repeating my code which is effect what i am doing now i.e.
each app (desktop, website, wcf) have copies on the same DLL and have references (add reference in vs 2008) ..
Ideas?
I think you would benefit best by using WCF (which wraps up .net remoting, msmq, etc.). Then you wouldn't have to copy a dll with each program... they can just point to a WCF service. This type of service oriented architecture is great for what you are describing.
From my experience with WCF so far, I have not noticed any performance hits, especially on an internal network.
Here's a good overview on WCF: http://msdn.microsoft.com/en-us/library/aa480210.aspx
Hope this helps!
If you deploy apps mostly on a single host, then chose publishing your middle-layer in GAC, supplying it with appropriate version policy.
If you deploy apps in a distributed environment, then use .NET remoting/WS/WCF. I think that remoting will be the fastest choice in your scenario.
Related
I have been developing n-tier applications using .NET for many years. But I still have no idea how to distribute the tiers/layers (dll) to other servers.
Let say, I have an MVC web application with 4 projects, i.e. MVC (UI), Business, Service and Data. Everything works fine if all class library dlls are in one server.
If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ? Or should I use other technology like .NET remoting or Web API?
Will that be a lot of work?
Is that one of the purpose of creating multi-tier application?
Thanks.
Update:
Do you have any links (from Microsoft) that explain in detail how to scale out an n-tier architecture application to multiple server by distributing the DLL?
If I want to scale out the application by distributing the Service layer (dll) and Data layer (dll) to other 2 servers, should I convert the class library to WCF Service Library project (with TCP or pipe as communication protocol for better performance) ?
Yep, since they are on different machines, you need some kind of communication mechanism that goes beyond simply DLL invocation.
Or should I use other technology like .NET remoting or Web API?
Which approach you choose depends on many factors like complexity, performance...There are many options like
WCF webservices
Simple REST calls with WebApi
a message bus i.e. NServiceBus
...
Obviously remote calls will also be slower having a potential impact on performance etc.
Will that be a lot of work?
It will be more work and in my opinion that "more work" should really be justified. Keep your architecture as simple as possible or better, only as complex as really needed.
An alternative approach could be to have some deployment pipeline that deploys your entire application on different server instances and have some intelligent load balancing strategy. The only thing you need to pay attention to in that case is to properly share the sessions between your instances (stateless would be better ;) ).
My 50 cents...
As far as I know WCF replaced .NET Remoting (MSDN).
Anyway... Someone before me said. If you don't have to scale the application, do not do it. Communication cost alone between services of any kind will slow things down considerably. Probably to extent, where it would be slower than it is now (which I am assuming is the reason for scaling).
Prior to scaling, I would first see where the bottleneck really is. For instance, if the problem is your DB server, then moving services and data layer to another server is useless, as you will still be using the same database. So, you need to first find out what your bottelneck is.
The easiest and least painful way to scale (in my opinion) would be to just add another IIS server and a load balancer that would direct traffic to either one of them. You would need to store sessions in a database or use dedicated server, but that is about all the change you will need. Plus, if one of your server fails, one will still operate.
By default, avoid premature optimalization.
If you have a only web site, I would keep it as simple as possible and only create logical layering. There are a number of options: typical 3 tier, onion architecture etc. The key is that later, if really really needed, you could still refactor your code and make your data layer a separate physical layer. But unless you are creating a new Amazon or something, this will probably not be the case.
If you are in the situation, for example, that you have a web site, but also have to expose a web api; you could choose to have the web site consume the web api. In fact, your web site would then become a very thin layer (maybe not even using ASP.NET MVC) because most of the logic would be in the web api.
PS - .NET remoting is old technology, consider WCF or Web API instead.
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 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.
Can anyone confirm the best way to integrate the repository pattern with webservices.... Well actually i have my repository patter working now in c#. I have 3 projects, DataAccess, Services and my presentation layer.
Problem is my presentation layer is a number of things... I have a ASP.NET MVC site, I have an WPF application and we are about to create another site + an external company needs access to our repository also.
Currently i have just added the services layer as reference to each of the sites... But is not the normal way to provide data access via web services? (WCF) - if this is the case will this break the services layer? or should i convert the services layer to a web service?
Anybody know what the PROS and CONS are of this, speed??
I think I understand your dilemma. If I understand correctly then your services layer consists of pure fabrications. http://en.wikipedia.org/wiki/GRASP_(Object_Oriented_Design).
If I assume correctly above, then your services layer should not be impacted at all by the introduction of WCF. WCF is essentially an additional presentation layer that provides interoperability, sitting between your UI presentation layer and any business logic layers. So your WCF services would then call your services layer, which may access repositories as needed.
WCF provides a high degree of interoperability so I think it is an excellent choice. I would use basicHttp bindings though, if you intend to interop with different programming languages as this is the most flexible. Don't worry about the speed. There are plenty of solutions out there to mitigate any bottlenecks that result due to WCF.
Good luck, and let me know if I can help in any other way.
Well first - not all callers have to use the same repository API; this is especially true of an external company.
WCF is interface based. This means that if you need to re-use some logic code, it is possible to use IoC/DI to inject WCF rather than a DAL (but using the same interface) - by using assembly sharing. It sounds like this is what you are doing. This works in many cases, but not all; fundamentally web-service based APIs often need to be designed differently in order to be optimal. It also isn't 100% pure from an SOA viewpoint, but it gets the job done, and allows more intelligent domain entities, so in an intranet (etc) scenario it is (IMO) perfectly reasonable.
An external caller would typically just use the wsdl/mex-based APIs (rather than assembly sharing), but anything is possible...
Maybe webservices are not the best way, if i have full access to the service assembly then i suppose it always better to assembly share the services layer with my applications.
My applications do similar things, but they all need to access the service layer - well the business logic and get back information...
In this case - its always preferable to use assembly sharing with the service layer rather than provide a WCF Web service using HTTP protocol or using TCP on wcf - for example?
Thanks again
Whether to share your Service/API assemblies with your client applications is fairly subjective. If you are a full Microsoft shop, and use .NET for your entire application stack, then I would say sharing the API is a great way to gain code reuse (you have to be careful how you design your API so you don't bleed domain concerns, like repositories, into your presentation.) If you don't have any plans to migrate your client applications to other platforms (i.e. you plan to stay on .NET for the foreseeable future), then I think its perfectly acceptable to share your Service/API assemblies (and even then, in a multi-platform client environment, sharing Service/API with .NET clients should still be acceptable.) There is always a trade off between the 'architecturally ideal' and the 'practical and achievable within budget'. You can spend a LOT of time, money, and effort trying to achieve the architecturally ideal, when the gap between that and the practical often isn't really that much. The choice NOT to share the API and essentially recreate it to maintain "correct" SOA, consuming only the contract, can actually increase work and introduce maintenance hassles that quite possibly are not worth it for your particular project at this particular time. Given that you are already generally 'service-oriented', if at a future point in time you need the benefit that contract-only consumption on the client can offer, then your already set to go there. But don't push too far too soon.
Given your needs, from what I have been able to glean from these posts so far, I think your on the right track from your services down too. A repository (a la Evans, DDD) is definitely a domain concern, and as such, you really shouldn't have to worry about it from the perspective of your presentation layer. You services are the gateway to your domain, which is the home of your business logic. Repositories are just a support facility that helps you achieve domain isolation from a data store (they are glorified collections really, and to be quite frank...they can be a bit of a pain in a dynamic and complex domain. Simple data mappers, (Fowler, PofEAA) are often a lot easier to deal with and less complex in the long run, and allow more adaptable behavior around your data retrieval logic to be centralized in your domain services.) Aside from heavy use of AJAX calls to REST Services, if you expose adequate Services/API around your domain, that is the only thing that your clients should have worry about. Wrap up all the rest of your business logic entirely within the confines of your domain, and keep your clients as light weight as possible and abstracted from concepts like 'Repository' or 'Data Mapper' and whatnot.
In my experience, the only non-service or API concept that needs to be shared across the Client-to-Domain boundary is Context...and it can be notoriously difficult to cross that boundary in a service-oriented application.