I have a VS2017 WebAPI solution that I am working on at the moment. I need to make a call to an assembly (included in the solution) from within the Controller. Much to my frustration it appears that I cannot make a call to methods within the assembly.
The graphic below I believe should supply sufficient detail for the right advice. Likely I am trying to do something with the WebAPI project that it will not allow (but I hope not) :-)
Update
On reflection the graphic doesn't appear to be all that legible. Within the PIInterfaceController I have added the following code:
Imports System.Net.Http
Imports System.Web.Http
Imports SPEN.PIInterface
Namespace Controllers
Public Class PIInterfaceController
Inherits ApiController
Dim piServerSetting As String
'Instantiate the SPEN PI Interface object so we can supply necessary data elements as required to extract the correct data from PI
Dim piIntfc As New SPEN.PIInterface(piServerSetting)
piIntfc.
End Class
End Namespace
My problem is that I am unable to access any of the methods from the PIInterface instance 'piIntfc'.
Related
So I am writing an ASP.NET Core MVC application where users should be able to upload an Excel file, when a file gets uploaded I need to read the uploaded file an create a Model of the data inside the file.
I am currently creating this model in my Controller method but this made my method quite long.
My current solution is creating a class inside my Controller which deals with creating a model from an Excel file but I feel like this is the wrong way to do it.
So my question is: What is the right place to put the code that reads my excel file and puts it inside a model?
You should create a new .NET Standard library and create there the class that builds the model.
The recommended way is to use the class as an implementation and an interface (IExcelModelBuilder) that exposes all the public methods of that class (ExcelModelBuilder). This way you can inject this service into your controller constructor and, as a bonus, you can easily unit test it too.
You can read more about Dependency Injection in .NET Core.
You can register the service in your startup file:
// This method gets called by the runtime.
// Use this method to add services to the container.
public void ConfigureServices(IServiceCollection services)
{
{...}
services.AddTransient<IExcelModelBuilder, ExcelModelBuilder>();
}
Step 1:Create a new .NET Standard library (Services)
Step 2:Add the reference into the mvc application of that library.
Step 3:Step two create a class that will be dealing with all the stuff like that if you have a limited number of tasks to perform ,
but if you want to separate it and wants a generic solution then Create an Interface (IUpload) and then implement all its methods in a class (Upload).also register the service in your startup file:
I am new in MVC application development.I am willing to develop a new project using MVC, i looked a lot for architectures that suits to MVC application.
After reading many articles and blogs i came to know that repository pattern can be used for this.
Based on my understanding before starting real project i created a dummy project structure like described below [ Not using EDMX file, entity framework in project, defined custom DAL ]
Name of my dummy application is Repository.I took Country,state and city relationship as example to develop dummy application :
Repository_DAL_V1 class library This library has class as below :
SQLHelper.cs : This class have methods to get executed for queries like ExecutenonQuery etc.
Repository_DTO_V1 class library This library has class as below :
CountryDTO.cs : This class is inherited from CountryModel.cs as [ CountryDTO:CountryModel ].This will be used to move data between all layers of application.If there is any property that is supposed to be used in business then this will be created in DTO not in model.
CountryDTOMapper.cs : This is used to map data from database in form of DataTable into collection of DTO object.
Repository_Implementation web mvc project This is UI Layer.
Repository_IRepositories_V1 class library This library has class as below :
ICountryRepository.cs : This is a interface having declared functions like SaveCountry() etc.
Repository_Models class library This library has class as below :
CountryModel.cs : This class has properties exactly for all columns of table in database.
Repository_Repositories_V1 class library This library has class as below :
CountryRepository.cs : This is a repository class having defined functions like SaveCountry() etc.
Repository_ViewModel_V1 class library This library has class as below :
CountryViewModel.cs : This will be build for Country View on screen.
above projects reference details :
Repository_DTO_V1 has reference of Repository_Models.
Repository_IRepositories_V1 has reference of Repository_DTO_V1,Repository_Models.
Repository_Repositories_V1 has reference of Repository_IRepositories_V1,Repository_DAL_V1,Repository_DTO_V1,Repository_Models.
Repository_ViewModel_V1 has reference of Repository_Repositories_V1,Repository_IRepositories_V1,Repository_DTO_V1,Repository_Models.
I need guidence from all of you to steer me in the right direction.
I don't se why not using EF would be any different from any other project you done layer wise that is. There is nothing wrong with you structure of things if you are comftable with using mulitple layers. I don't know what your project is about but you should consider better naming, like Project name (Repository) and Implementations is better named Web.
EDIT
I recommend you to use Entity Framework 5 with Code First, that is if you want to use a ORM?
I'm certainly with you on the desire to give EF a miss.
As #Dejan.S says, The architecture you'll need depends on the size of your project.
I would start off simple, perhaps with 3 projects:
A web project.
A service project that controllers use to access models and business logic.
A domain project with your models and data access.
If you need to separate things (like a DAL), you can still do that later.
Also, check out ServiceStack's MVC Power Pack. You get a great micro ORM, IoC, caching, fast serialisers and so on out of the box.
I am using Play! framework 1.2.5 for one of my application. Initially I was resolving dependencies either by creating new instance of the class or using factory. But my application grows and it becomes harder to manage dependencies in such way. I'm going to move to dependency injection with Google Guice
Looks like, for every controller, I have to write
requestStaticInjection(MyController.class);
to inject service in controller
#Inject
static MyService mySerivce;
This is frustrating, I don't like that controllers has static methods and can access only static variables. I would like to pass dependencies to constructor of controller and I don't want to declare static fields.
Why methods of play controllers are static ? Is it some kind of limitation ? Is there are other good way to inject classes into Play! controllers
Old question, but I got the same problem and I found my answer here http://typesafe.com/blog/announcing-play-framework-21-the-high-velocit Though, It's not for the same Play version as you are using...
Play 2.1 now supports a new routes syntax that enables calling injected controllers instead of static methods. Simply prefix the controller method in the routes files with an "#" symbol
GET / #controllers.Application.index()
in your conf/routes
Is there are other good way to inject classes into Play! controllers
No. You should not create a service in a controller - make it a regular class that does not extend Controller. Then call the service class from your controller. Keep your controller code to a minimum - there is a lot of bytecode magic there, so keep controller code simple (lookup object, render results, that sort of thing)
This seems like a fundamental Web Services problem. However an elegant solution is elusive based on some research I have been able to do. I guess I am missing something here
I am using a WCF client to connect to a External web service of which I have no control. The external WS is java based. There are a bunch of assemblies which are provided to call the methods in web service. These assemblies have base classes and derived classes. The web service methods can take Base class as param whereas from the WCF Client I instantiate a Derived class and pass it to the method.
To simulate this scenario, I created a small project with one ClassLibrary which has a BaseClass and a DerivedClass with one method.
Then I create an asmx web service and add a HelloWorld method inside it. I add a reference to the ClassLibrary. This method takes a BaseClass type param.
Then I create a Service Reference to the ASMX web service. In the proxy class, I add a XmlSerializerFormatAttribute to the method if it is already not there.
From the WCF client, I call the ASMX web method
BaseClass bc = new Derived();
ServiceReference1.TestService ts = new WCFTest.ServiceReference1.TestService();
lbl1.Text = (c1.HelloWorld(bc));
The call fails with error
The type ClassLib.Derived was not expected. Use the XmlInclude or SoapInclude attribute to specify types that are not known statically.
The only way I could call this web service method was by adding XmlInclude attribute to the BaseClass in the ClassLibrary.
In my scenario, this library is a dll provided by an external vendor. I cannot add attributes to its classes. I have looked a DataContractSerializer and KnownTypes and XmlSerializer ctor. However those solutions do not seem to be applicable in my scenario.
How can I make XMLSerializer see the Derived classes in the assemblies I have referencing in the WCF Client? Is there an elegant solution?
Thanks,
Hem
Including your own type mapping for an XmlSerializerOperationBehavior may just work, but I haven't tried this (see GetXmlMappings).
http://msdn.microsoft.com/en-us/library/system.servicemodel.description.xmlserializeroperationbehavior.aspx
Alternatively, forcing use of the DataContractSerializer via a DataContractSerializerOperationBehavior (as opposed to the XmlSerializerOperationBehavior it's using now) may work too, if you specify your own known types
http://msdn.microsoft.com/en-us/library/ms576751%28v=vs.85%29.aspx
Finally, as a last resort, you can force use of the DataContractSerializer using the DataContractSerializerOperationBehavior, then specify your own DataContractSurrogate to force use of the XmlSerializer where you can pass custom types to its constructor (which circumvents the requirement for the XmlInclude attribute).
http://msdn.microsoft.com/en-us/library/ms751540.aspx
Hope that helps.
Greetings,
Trying to sort through the best way to provide access to my Entity Manager while keeping the context open through the request to permit late loading. I am seeing a lot of examples like the following:
public class SomeController
{
MyEntities entities = new MyEntities();
}
The problem I see with this setup is that if you have a layer of business classes that you want to make calls into, you end up having to pass the manager as a parameter to these methods, like so:
public static GetEntity(MyEntities entityManager, int id)
{
return entityManager.Series.FirstOrDefault(s => s.SeriesId == id);
}
Obviously I am looking for a good, thread safe way, to provide the entityManager to the method without passing it. The way also needs to be unit testable, my previous attempts with putting it in Session did not work for unit tests.
I am actually looking for the recommended way of dealing with the Entity Framework in ASP .NET MVC for an enterprise level application.
Thanks in advance
Entity Framework v1.0 excels in Windows Forms applications where you can use the object context for as long as you like. In asp.net and mvc in particular it's a bit harder. My solution to this was to make the repositories or entity managers more like services that MVC could communicate with. I created a sort of generic all purpose base repository I could use whenever I felt like it and just stopped bothering too much about doing it right. I would try to avoid leaving the object context open for even a ms longer than is absolutely needed in a web application.
Have a look at EF4. I started using EF in production environment when that was in beta 0.75 or something similar and had no real issues with it except for it being "hard work" sometimes.
You might want to look at the Repository pattern (here's a write up of Repository with Linq to SQL).
The basic idea would be that instead of creating a static class, you instantiate a version of the Repository. You can pass in your EntityManager as a parameter to the class in the constructor -- or better yet, a factory that can create your EntityManager for the class so that it can do unit of work instantiation of the manager.
For MVC I use a base controller class. In this class you could create your entity manager factory and make it a property of the class so deriving classes have access to it. Allow it to be injected from a constructor but created with the proper default if the instance passed in is null. Whenever a controller method needs to create a repository, it can use this instance to pass into the Repository so that it can create the manager required.
In this way, you get rid of the static methods and allow mock instances to be used in your unit tests. By passing in a factory -- which ought to create instances that implement interfaces, btw -- you decouple your repository from the actual manager class.
Don't lazy load entities in the view. Don't make business layer calls in the view. Load all the entities the view will need up front in the controller, compute all the sums and averages the view will need up front in the controller, etc. After all, that's what the controller is for.