I am working on a Restful WCF API. I figured out it would be nice to have one service contract for API related to Users (IUserService) and then for example another one for Posts that users add to the database (IPostService). This approach makes it easier to read the code , as well as to collaborate on the code, since several people can work on separate files.
However, this way, to make a requests I would have to call <url>/UserService.svc/user/123 to get a user and <url>/PostService.svc/post/456 to get a post.
Is this a viable solution , or should I have just one service for a case like this ? If yes, is there a way how to make it easier to collaborate and read the code ? Maybe with partial classes?
I don't have much experience with theses technologies and C# in general, so I will appreciate any help :)
Thanks.
Your solution is definitely viable. And even more scalable if needed in the future than the partial classes solutions. By having the ability to split completly in multiple specialized services.
Related
This is a theoric question about how to organize web service.
Building a web service using ASP.NET Web API you can create a lot of controllers and web methods inside them. However, maintaining many controllers and methods in the same solution can be hard.
What are the criteria that shuold be used in order to choose to split a solution in two or more?
What advantages and disadvantages derives from using a single solution with many methods and controllers and the advantages and disadvantages of using many solutions ?
I guess first question will be: what is the number are you talking about with "a lot of controllers"?
The main disadvantage I see when dealing with huge solution is load (CPU? RAM, Resharper caching). I do remember I had a solution of 54 project and it building takes over 3 minute. So we had to extract one small solution for development and full solution was loading only on integration of our part. (Well SSD probably helps here)
But also it is semantics. The best way on my opinion is making separation based on complete blocks for example you extract interface and then it implementation goes to another solution or project.
What is the best way to integrate webservices to an existing C# 4 project to serve data provided by this application ?
These webservices need to be accessible by different types of client like PHP and access need to be secured.
I started investigations with WCF but it seems to be very complex for small things...
Is there any frameworks easier to implement that ?
I agree with John that WCF can be easy for small things. You may want to consider using WCF Data Services if you have an existing data context (Linq2SQL or Entity Framework) - this makes it pretty easy to serve up your data and also create custom service methods to perform specific actions.
I can provide more specific answers if you elaborate in your question what you're looking to do.
I hope this helps.
Alright guys, I'm in a little over my head on this one and am hoping someone can point me in the right direction, as I'm not really sure how to implement this.
I've got a piece of hardware that exposes a c#.net API. Great. Works wonderfully. I want to collect data from this hardware using the API (so, a small c# app that does what I need) and then display the results on a web page. Currently, I have the c# app grab data I care about and stick it in an RRD file, then I have the web page load the relevant data and display it to the user.
My question, then, is what do I do when I want to expose some of the API functionality to the user? How do I go about making the 2 projects talk using .NET?
Some clarification: The reason there are two parts is due to modularity. The attached hardware and API can change, but as far as any client request is concerned, nothing's different, everything's just a web request to them.
Very little experience in big .net projects, so if you've got a better idea, let me know.
The easiest way I can think of would be to use something like NServiceBus to post a message to the other component which communicates with the hardware. The hardware piece would pick up the message from the bus, process it and put the response back on the bus.
It's not a perfect solution, but I think it's definitely workable.
You should be able to find everything for it here.
Left it here for a few days to see if anyone else had any ideas. I ended up scrapping the whole idea and consolidating everything into the web app. Not my initial preference, but it works okay. Thanks to Terrance for the brainstorming session under my question.
Easy. Create a class library for the device handler. Add a public class which exposes a nice interface for the web app. Add a reference to the class library. Create your class and use it.
I am in the process of designing a web application which will have multiple installable modules that provide different functionality. There's a lot of common stuff going on here and I have 3 C# class libraries that I know will be easy to use on different projects.
The bit I am stuck on is the actual website itself. Ideally I'd like to make an ASP.NET page library that can be re-used over multiple projects but I understand that this is not possible.
How do you guys structure your website projects so that pages can be re-used across multiple projects? So far the only solution I've come up with is to create a repository in SVN and have it referenced in the svn:externals properties of the main project. This allows me to add pages to that directory that are common to all websites, and I know I will be able to use this to check them out to other projects. However, I feel this is a bit clunky and will cause problems when creating new projects (there'd be a number of steps to creating the new solution, ensuring that the right externals are in place).
Is there a better solution? What is the best way when you want to share common ASPX files across multiple client projects? How do you manage changes against them?
Thanks in advance!
EDIT:
Many thanks to David for his response. I've had more thought on this and thought I'd list some of my more concrete ideas/concerns. Firstly, a bit more about the project(s). Primarily, it's a CMS. However, we also have clients that will want CRM, and there's also clients that want neither and want an entire bespoke system from the ground up.
In my original post above, I spoke about having subdirectories of the main root (e.g, cms), using svn:externals to allow easy re-sharing of web pages across multiple projects. I am beginning to think this is the only way to do this. One thing that bothered me was if the client's url was:
http://www.shotgunanddribble.com/cms/content.aspx
However, I think I can use the Application_BeginRequest to mitigate horrible urls by rewriting them according to the configuration of the client's site. E.g, if a customer was just a CMS I could rewrite their Top-level-domain to /cms/. Same with if they were a CRM. If they were both:
http://www.shotgunanddribble.com/ -> /cms/
http://crm.shotgunanddribble.com/ -> /crm/
Is there any downside to using these kinds of rewrites? I think that, unless anyone else has any magical ideas, svn:externals is my only hope.
The actual code is easy enough to put in other assemblies and inherit from, but the ASPX files are definitely a different story. How about a common library of user controls to contain most of the display content, and each project would have its own pages which mostly just frame the user controls? I've never tried it, so there may be some "gotcha" that I'm just not picturing right now.
I have two C# programs and I want to send some data back and forth between them. (And check if the data arrived to the other application.)
The two programs will always run on the same computer, so no networking capability is required. I've already read some questions with similar topics here, but I'm not entirely sure which is the right method for me. (WCF, Remoting, etc.)
What I want to know, is which one is the easier to implement for a beginner in C#?
(I don't want it to get too complicated anyway, it's only a few integers and some text that I want to send.)
If there isn't a real difference in difficulty, what advantages does one have over the other?
I'd really appreciate some simple example code as well.
Thanks in advance.
You can use Pipes to send data between different instances of your application. If you just need to tell the other instance that something has happened you can send messages from one application to another by using SendMessage api.
WCF essentially packages up the various methods of communication between applications (web services, remoting, MSMQ etc) in a single package, so that they are programmatically the same in the way that they are used, and the detail of what method is used is left for configuration of the binding between. A slight simplification perhaps, but essentially what it's about.
It is worth getting into WCF if you need inter-process communication, and this would certainly be my advice as to the way to go with this. It's worth looking at IDesign, who produce a number of articles on the subject, as well as some reusable code libraries, that you may find useful. Their Juval Lowy has also written an excellent book on the subject,
Another good point about WCF is that if your requirements ever change and all of a sudden you have to move one of the application to a different machine, requiring now network capability, you will only need to change configuration on both sides, instead of having to recode.
Plus, ad David said, WCF is a good tool to have in your bag.
Cheers, Wagner.
I found MSMQ is simple to implement.