When using the SQLEntityConnection F provider # type, the generated types provided by this type provider cannot be used by other F # nodes and, indirectly, any other nodes, such as a separate ASP.NET application, console application, C # program, etc. Thus, the type provider must be labeled both internal and private.
In addition, functions using the type provider may not be available than types provided by the type provider. Thus, such functions should also be marked, both internal and private.
What is the correct way to map these types, which need to be labeled both internal and private, for something publicly available that can be used outside of the same assembly?
A simple template using the Entity Framework to get an object from DbContext, update some properties, call some methods, update several child objects, etc., and then call SaveChanges () on the DbContext. Since the resulting object is still bound to DbContext, and DbContext is still in scope, changes are tracked automatically, and updating is simple.
Is it possible to use the same workflow with a provider like SQLEntityConnection F #? I guess not if the object needs to be updated outside the assembly where TypeProvider is used, for example. in a C # MVC project, given the limitations mentioned in the original post. What is a comparable approach to performing basic CRUD operations using a provider of type SQLEntityConnection? Unfortunately, official documentation is not enough in the main operations. Perhaps an alternative type of provider is a better, more functional choice.