I have developed a Xamarin Forms App (iOS and Android) using PRISM. We are using Realm as offline storage.
For logging, we are using AppCenter which captures crash logs and exceptions.
We want to implement centralized logging for overall applications using Aspect Oriented Programming (AOP) which can be used using IoC containers such as AutoFac which provides an IInterceptor interface for capturing low-level data related to methods, arguments, and more.
Now the problem is we cannot bind these interceptors with the dependency injection (IoC) provided by Prism. We have to use Autofac which will fail the purpose of using Prism in our application.
Is there any way, we can use Interceptors with PRISM framework or any other way to achieve centralized logging in prism framework which can capture data of each method being executed and how much time it takes to execute and other related log data?
I took references from the below links :
https://www.encora.com/insights/autofac-and-dynamicproxy-how-to-do-aspect-oriented-programming
https://blog.ivankahl.com/introduction-to-aspect-oriented-programming-in-dotnet-with-autofac-interceptors/
https://medium.com/swlh/easy-aspect-oriented-programming-for-transaction-handling-in-net-5-1a1b0c763935
https://ardall.wordpress.com/2019/04/11/aop-in-net-core-using-autofac-and-dynamicproxy/
Related
How to structure a SignalR core project for an enterprise application?
An application that has a lot of functionalities as so a lot of classes and methods to invoke.
Multiple hubs for different areas?
Only one hub that dispatch to different classes?
How to arrange the project folders?
I can't find any viable example over the simple tutorials?
Any suggestions?
I'm afraid that this question will be closed because it is not to a specific problem but I will put my suggestion.
Since you will do a lot with SignalR and it would need to resolve different specific problems I would recommend to create a .NET Core Web Application to connect your product with this service using SignalR. You should start first reading this SignalR documentation.
So you will have one app that is responsible to handle those connections and your app must have various hubs for different business logic. Create interfaces and managers that can be shared between hubs and inject the HubContext in the managers to call methods to the clients.
Since you mentioned enterprise application I would extremely recommend you to look at Azure SignalR to manage and handle your connections.
Are you planning on using ASP.NET 4.x framework or .NET Core?
ASP.NET Documentation states that it makes no difference between single and multiple hubs from a performance standpoint. ASP.NET Docs
That does not mean you may not have performance issues overall, that will highly depend on your design/implementation.
.NET Core does not appear to state either way. Core Docs
According to their GitHub repo, you can have multiple if you want. Understanding that one of the differences is that under .NET Core each hub will have its own client connection.
I am creating small project in xamarin.form (to learn xamarin and mvvm pattern ), where my mobile application will be connect to SQL Server database. On every forum people suggest to use Web Api to get json's from database and next in xamarin application i go under link where is json, parse it and its done. I did an test project which is doing that and it works very well. Unfortunatelly after few days I realized that all data is visible.. If I enter under url/api/subject I get this data in json.
My question is. Should I connect from my xamarin application directly to SQL Database OR is there any way to not showing json's in browser?
To function correctly, many mobile applications are dependent on the cloud, and so integrating web services into mobile applications is a common scenario. The Xamarin platform supports consuming different web service technologies, and includes in-built and third-party support for consuming RESTful, ASMX, and Windows Communication Foundation (WCF) services.
This article discusses this topics.
For customers using Xamarin.Forms, there are complete examples using each of these technologies in the Xamarin.Forms Web Services documentation.
I recommend you learn more about REST architecture
We have an ASP.Net C# application that requires some form of a web services implementation for integration with other applications. Currently we have been looking at servicestack and also using an ESB e.g. Mule.
I am trying to figure out the best way to integrate an ESB like Mule into our ASP.Net application.
Do we need to build a web service into our ASP.Net application so that an ESB can integrate with it?
If yes what would be a good approach for selecting a web service type (e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an ASP.Net application and Mule?
Do we need to build a web service into our ASP.Net application so that
an ESB can integrate with it?
Usually it's the other way around. An integration middleware, like Mule, speaks tons of protocols just for the sake of being able to connect to existing systems without changing them.
If yes what would be a good approach for selecting a web service type
(e.g. REST, WCF, SOAP, Servicestack) that will be compatible with an
ASP.Net application and Mule?
If your application has really no pre-existing channel you could use to integrate with (not even a simple web form HTTP POST? really?) and you want to expose an API so an integration middleware can connect to it, pick the architecture/technology that maps to the API style you're creating (REST for a resource oriented API, SOAP for a RPC oriented API).
This sounds backwards. What are you required to integrate with, and what capabilities are you trying to provide?
A web service is decoupled from its implementation, you would choose to use a web service if you're trying to expose your system capabilities in an interoperable way so that it's accessible by a broad range of clients.
What you do within a web service is up to you, i.e. you could then for example connect with your ESB. Nothing is precludes you from doing that. ServiceStack also supports hosting from within an existing ASP.NET (or MVC application) see the Hello World example for different ways of configuring ServiceStack.
REST / RPC has to do with the design of your web services and ServiceStack supports both models. i.e. inherit from RestServiceBase if you want to provide different implementations when the service is invoked with different HTTP Verbs. Inherit ServiceBase if you want the same implementation to be used no matter how it was invoked. This article shows the difference between REST vs RPC/SOAP - and how you can support both in ServiceStack.
So if your exposing a single operation (or want to support SOAP) use ServiceBase, if your exposing a 'Resource' where you want to allow it to be managed using different HTTP Verbs use RestServiceBase.
I'm working on building an application that's based on SOA. I have bunch of business services that I should make them available as components to another applications (so I'll use web services -SOAP-).
The application presentation layer is MVC.
1- Model: Contains DataBase methods (ORM is used).
2- Controller: Contains calls to the model methods as well as methods to handle simple view actions.
3- View: Contains rendering content only.
So, can you give me a simple scenario how can I combine web service with my MVC application, my suggestion is to separate the model as web services, is that right?
I'd tackle it this way: (YMMV)
Build a data tier assembly housing all your data access. Call it the DAL. It will contain all data access methods. This will enable re-use, but also allow for methods used by one application below. This is where your EF model can live.
Build 2 web projects: MVC and web services. Each will implement business logic to satisfy their respective requirements. They'd reference and call into the DAL as needed for data access. As you noted, they're both presentation-tier services. One has a user interface, the other is a communication endpoint for remote web service consumers.
Deploy both onto an application server as needed. Suggest creating 2 applications/sites in IIS - (i.e. "Web" and "WebServices"). This separation of applications ensures that one can be changed/downtimed/versioned without effecting the other.
The MVC project/app will still have its Models, Views and Controllers as per normal. The biggest change here is that the Models would be used only for ViewModels as needed. It would contain any business logic to satisfy the UI requirements. Its controller methods would call the appropriate DAL public methods as needed.
The web services project/app would be able to be changed independently as needed, while the data access would remain.
1) Place all your service operations behind an interface.
2) Consider using an Inversion of Control container to utilize dependency injection in your application. This allows you to mock your dependencies and unit test your controller logic more easily. Some examples are Windsor, Ninject, StructureMap.
3) Consider using strongly type view models for your views, instead of the objects that your ORM works with. You'll want to set up some mapping classes to help manage this, but a lot of the pain can be taken away by using something like AutoMapper.
Here's some good links on the subject:
How we do MVC – View models
ASP.NET MVC View Model Patterns
Never use web services for the sake of using web services: You should first have a problem that needs solving, and see that web services are the best solution to your problem. So depending on your need, web services can be used in a variety of different ways.
For example, since you say MVC is your presentation layer, you may want to insert web services as a layer between the Model and the Controller. Rather than invoking your model (data layer) directly, the Controller invokes your web services and provides a web-based front-end to the services that would otherwise be available via your SOAP API.
Another option is to make both your MVC front-end and the SOAP services access a common business/data logic layer, each providing their own "API" for the same back-end.
But again I emphasize: web services should not be used as solution in search of a problem. If it's not obvious to you where the web services should fit into your architecture, you are very likely better off without them.
What is the best method/technology to sharing the same data access layer between WPF, Silverlight, and ASP.NET?
I am using ADO.NET Entity framework, and was thinking of a creating a DAL using the Repository pattern.Then using the RIA Services as a dummy middle man to connect Silverlight and ASP.NET. Is this a solid plan or are there other better solutions out there?
One of the solutions I like to use is the following :
- Have a project storing only the entities (for example : Player, Game, Entity) with no reference to the database at all.
- Have a project implementing the repository pattern (Repository, Repository etc...)
- Use ADO.NET Entity Framework code first approach to map with the database (it creates a dynamic child object of your entities contain in your project, see ScottGu's blog for an explanation on how to use it)
Connecting Silverlight to your pattern can be done with Ria Services or classic WCF services. Usually I try to use WCF whenever possible as Ria Services is not really compliant with an MVVM development.
If you want to use WCF and share your DAL entities with Silverlight you can create a MyDal.Silverlight Silverlight class library project and add symbolic link instead of copies of every entities you will want to share with Silverlight. Then when you'll add a service reference with visual studio it will be smart enough to not create copies off Player, Game and User to you Silverlight project.
If you want to use Ria Services it will create copies of you entities anyway.
Hope that helps
John
RIA Services
RIA services will certainly take the burden off you for all the WCF plumbing. It has a few minor flaws (lack of certain data types), but there are workarounds for most problems.
The validation model (using attribute decoration and custom validators) is very strong and a great place to hang business rules.
RIA coexists happily with ASP.Net, so that is another plus. Behind the scenes it is just another WCF service. We are happily using RIA services with MVVM and Prism.
ADO.Net EF model
This is a tried and tested feature rich model. The only problems I have found related to many-to-many relationships. Again there are workarounds.
DAL
As RIA change sets are managed for you on anything, including POCO, this is the area that will need the most attention. It is considered "bad" to expose your EF model directly to RIA and that will certainly not insulate you from data changes.
I can't specifically recommend any one pattern yet (still experimenting), but make sure your choice is compatible with IQueryable. The paging feature and appending to Linq queries for server-side execution are features you do not want to lose!