Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I developing software for taxi services. My software consist from wcf service as server and wpf application as client. Functionality is growing and my wcf service has more then 50 methods now. I thinking about split my one big WCF service to couple of small services.
Is it a good idea to do so?
I would say yes if you can define a clear separation of responsibilities for each of your services. You should try to avoid or minimize coupling between services though. Keep in mind you'll break existing clients if you do change the contract, but it sounds like you are in control of these.
This is quite a common scenario, and you can help yourself by ensuring your service layer is essentially a facade to make it easier to move things around.
IME, if splitting the service up would just create a lot of replicated code for common functionality (like DB access), or would complicate things by needing to add stuff like additional functionality for the services to talk to each other, I would suggest no.
Another reason: your fault-tolerant scenarios now become more complicated. It is one thing if your entire monolithic service dies - then nothing works. But if you have 4 related services that need to work together, you now have to intelligently handle partial failure scenarios like what happens if service #3 goes down, and the other services have half-done jobs that need it. Now you have to be able to get things back to a consistent state while waiting for #3 to come back up, or be able to persist stuff so you can get back to it when it does. Your number of error messages had just increased as well.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I would like to build a c# spa application using angular with real-time messaging signal-r. The signal-r should read the data continuously from a data source and publish the updated data to the user and store the data in a database as well. It should also enable the chatting of the users.The expected number of users is around a hundred.
For such application what should be the best architectural structure of the solution? Should I implement two (three?) projects, e.g. one for the web app and the other for the signal-r, running as two applications? Then, in this case, how can I do the messaging between the applications? Or should I implement a single project for all of these? It would be best if you can provide the pros and cons of these alternatives or provide any other option.
Start with one project.
For 100 simultaneous users, you aren't even close to worried about load. Any simple hosting plan would take care of it easily. If you get more, ASP.NET and SignalR work just fine behind a load balancer (though certain operations can get more complicated).
A properly architected application won't be difficult to split into multiple processes in the future if it ever came to that, and doing so now is just adding mounds of complexity for no appreciable benefit. This goes double since it sounds like you are just starting out.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I'm writing a web api app that I have divided into various projects such Web, Services, DataAccess - so basically the web api controller contacts the service layers which then can access the data access layer.
I was returning just a bool to let me know if the data access method has completed ok, then picking this up in the service layer and then back to the controller...where I can then respond with a HTTPStatusCode of 200, or 500 etc..depending whether or not the operation has returned a true or false.
Instead of bool is it good practice to use HttpStatusCodes instead...or should HTTP status codes only be used in the Controller - to return a response to the app that's calling the web api or should it be something else?
Thanks,
First of all classes should have the least possible knowledge of the world around them. Suppose you implement the repository pattern to fetch data. Your repository (data access layer) should not even know about HTTP, nor it should expect to be a part of web application. Its only concern is accessing a particular table.
It’s difficult to suggest specific solution without understanding the big picture, but you may consider the following:
Raise an exception if your application depends on data that couldn’t be fetched. It’ll propagate as 500 response.
Use enum instead of bool to make code more readable.
Create DataResponse class to incapsulate result of data access operation. You may then use the adapter pattern to adapt DataResponse to HttpResponse.
Vague question, but I'll attempt an answer.
This really depends on the reason for separation between the layers, and what each layer is concerned with. One question I would ask myself is why do you have a Service layer? Is it because it contains the business logic? Is it because intent is to have an option to reuse it outside WebAPI context? Or do you expect Service layer to have dependency on WebAPI context (i.e. that it is a web request, and not service being reused say inside a winform.)
Most likely, you want to constrain dealing with HTTP particulars to the Controller (IMHO, this is obviously just my opinion). But I'd refrain from using it as a hard and fast rule.
You shouldn't be propagating http status codes down or up the line. If you do then you are injecting dependency on what you worked so hard to decouple. One of the great things about N-tier architecture is that yeah, your web layer may be primarily used for interacting with your service layer but what happens when you want to hook up a native mobile application to call it, or a windows service to call it, or a desktop app to call it. You are basically handicapping its potential by trying to persist that error up and down the chain.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I want to use microservices architecture for my next project based on ASP.NET core.
I could exchange between the services via REST but it is really heavy to maintain.
Is there an other way for communication between microservices, for example over event bus like vertx.
I could use rabbitmq, but do not know, if it is a good option.
I think Rabbit MQ is going to work OK, especially if you have many consumers i.e. need load balancing, and/or if you need messages to be persistent, and also if conceptually, your micro-services are OK processing messages.
Otherwise, since you’re considering REST, I’d recommend WCF instead.
Just ignore Microsoft’s examples, those are too complex. You need to make an assembly containing protocols (in WCF terminology, service contracts) + messages they send/receive (in WCF terminology, data contracts) that’ll be shared between your services. Having a shared assembly will allow you to get rid of that enterprise-style XML configuration nonsense. This will also make maintenance simpler than REST, because the compiler is going to verify the correctness of your network calls: you forget to update one service after changing a protocol, and the service will stop compiling.
Here’s my demo which uses WCF to implement zero-configuration client-server communications in C#.
It’s currently set up to use named pipe binding i.e. will only work locally. But it’s easy to switch from NetNamedPipeBinding to NetTcpBinding which will do networking just fine.
P.S. If you’ll pick WCF, don’t forget the abstraction can and will leak. Any network call may fail with any network-related exception. Also you’ll need to reconnect sometimes (if you don’t want to, and your don’t have too many messages per second, you can use a connection-less protocol like NetHttpBinding but those are much less performant).
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have earlier developed an application that exposes a set of RESTful services. I have designed business logic implementation classes and corresponding repository classes completely stateless and they get instantiated every time there is client request. Now I am developing another application with few RESTful services. In this case, one of the services gets data from some other external service and needs to cache that data for some amount of time. I am thinking to cache that data in my application DB and provide it for each request by creating a new business class object. But here I have a doubt - is this correct design? Should I make the business logic class singleton and maintain state (i.e., cache data in memory)?
Please share your thoughts.
Thanks
I would use web server level caching instead. In asp.net you can use the Cache object, either backed by memory or an external cache provider of your choice.
After some literature study, I conclude that there is nothing wrong in having singleton classes. RESTful services are just resource interfaces for external world but how they will be managed is completely internal. Also I realized there is no need to have end-to-end mappings from data transfer objects (that take requests and send responses) to database columns. My DTOs, in many cases, map to model objects which map to DB tables but I have also designed those three items differently.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I would like input on the design I currently have planned.
Basically, I have some number of external instrumentation, each of which should always be running, collecting specific data. My thought was to create a service for each, always running and polling the instruments, performing logging, etc. There could be one instrument, or there could be 40.
However, I need one application to consume all this data, run some math on it, and do the charting, display, emailing, etc. The kicker is that even if this application is not running, the services should constantly be consuming data. Also, these services should almost always be supposed to run on the same machines as the client application itself, but the ability to network them (like .NET Remoting used to do) could be an interesting feature.
My question is... is this the best design? If it is, how do I go about doing the communication between services and application? I've looked into WCF, but it seems to be geared towards request-response web services, not something that is continually streaming data to anything that might listen to it. Alternatively, should I have these services contact some other Web Service using WCF, that then compiles the data for use in a thin client viewer that polls the web service often?
Any links and resources would be greatly appreciated. .NET namespaces for me to research are also appreciated. If I wasn't clear about something let me know.
Just a thought....but have you considered perhaps adding a backend database? All services could collate data and persist it then your application that needs to process the information can just query the database rather than setting up loads of IPC between the services.
WCF can handle streaming. It can also use MSMQ as a transport, which will ensure that no messages are lost, even if your instruments begin producing large quantities of data.