So I want to create my own Azure Table class that uses only IronPython for declaration. To define such class in C# i use property. How to translate it straight into pythonic way?
I now that when I overrride C# class all properties thanks to reflection to get_Name and set_Name and in this way I can override them. But I want to create new Properties visible in C#. 1
In Python there is property function to create such. But will python property be recognize by C#? I can setter and getter functions rename to C# reflection model. 2
Maybe in assemblies there are some way to create property in other way then syntactic sugar? I didn't find it.
I want to show that there is possibility to use Azure Tables in only IronPython.
I am not familiar with Iron Python. This blog post may help, but it requires us to define the data model in C# and then invoke the data model from Iron Python: http://blog.sharpthinking.com.au/post/2009/02/20/Azure-Table-Storage-in-IronPython.aspx. In the end, table storage is a REST service. So we can use the REST APIs to work with table storage in any language of our choice. If it doesn't offer a client library in the language of our choice, we can build our own. Some third party libraries for OData may also help, as table storage uses OData protocol. I would recommend you to have a look at http://code.google.com/p/odata-py/.
Best Regards,
Ming Xu.
Related
In web api based projects I often use different classes for one entity. Lets say you use class A in your buisness-logic and if you want to return a result you use a class ADto. I am new in using javascript, typescript with node.js based projects. In ASP .net core you often use automapper to transform types. What is the common way you do that in typescript? I did not come to a good result. Writing that boilerplate-code by yourself is not the way to go I think.
I'm looking to effectively create logic via attributes on a .net core API project that, depending on a attribute will serialise or de-serialise while ignoring certain properties.
Eg.
If a property was decorated with [OutputOnly] it would not allow users to pass it in via the API, but the API would be able to return this value.
Inversely [InputOnly] would enable users to only pass this value in, but an API would not return this.
The issue I am having is JsConfig static and the property (IgnoreAttributesNamed) that enables Ignoring fields is a singleton too and not part of the Scope functionality in JsConfig.With()
My idea currently is to have an InputFormatter and an OutputFormatter in .net core, that will handle the this logic, but need to be able to config which properties are ignored in those contexts
any suggestions would be greatly appreciated :)
I don't really understand what the goal is here, you would use a Request DTO to define which Parameters a Service Accepts and Response DTO to define what your Service returns, the explicit purpose of the Request/Response DTOs is to define your Services Contract, i.e. the most important contract in your System, whose well-defined interface is used to encapsulate your systems capabilities and is what all consumers of your APIs binds to.
The C# POCO used to define your Request/Response DTO classes should be considered as a DSL for defining the inputs/outputs of your API, trying to collapse and merge their explicit intent of your APIs into multi competing Types with custom attributes is self-defeating, it adds unnecessary confusion, blurs its explicit definition which invalidates the primary purpose of having service contracts which is what all metadata services look at for documenting your API and generating the typed bindings in different supported languages.
So the approach and desired goal for using custom attributes for controlling serialization behavior so you can reuse the same types in different contracts is highly discouraged, but should you wish to continue with this approach you can refer to this answer for different ways to Ignore properties in ServiceStack.Text, specifically ShouldSerailize() API which will allow you to dynamically specify which fields ServiceStack.Text should serialize, if you intend on implementing a convention you can delegate the implementation to a custom extension method, e.g:
class MyRequest
{
public bool? ShouldSerialize(string fieldName) =>
MyUtils.ShouldSerialize(GetType(),fieldName);
}
Other than the linked answer the only other opportunity to manipulate serialization is potentially to use the built-in AutoMapping utils for selecting which properties should be copied over and the Object Dictionary APIs for converting C# Types into an Object Dictionary and manipulate it that way, then can dehydrate it back into the C# type after applying your conventions.
In UVM, factory is the most important thing. So how it is implemented inside. Means how it stores the various objects and create a universal database.
I know something like it has some assossiative arrays, one with key as object name and another with key as object type. But I don't know how this 2 arrays can build the database? Even I don't know that my information is proper or not.
Please also list out some related classes for factory implementation and modification. (Like umv_resource is one maybe.)
This DVcon paper Using Parameterized Classes and Factories: The Yin and Yang of Object-Oriented Verification was written with the UVM factory in mind before it was publicly released. All the same principals apply.
I want to know how C# collections are represented in memory? Are they represented as linked list or an array.In my project I have to make extensive use of list and performance is critical, so shall I create custom generic Linked List(with some additional features) or shall I use generic List class. Any help will be highly appericiated.
Use Reflection (or ILSpy, etc) to view internal realization of c# collections
This is an embarrassingly basic n-tier question.
I've created a DAL project in VS2008 with subsonic. It's got a widget class, a widgetcollection class, and a widgetcontroller class.
I've created my Business logic project (no I can't put it in the same tier) that references it. Using certain business criteria, it selects a collection of widgets in a function that returns a widgetcollection.
My question is: how does my GUI layer bind the collection to a grid? I know that the widgetcollection is a valid datasource for a datagrid, but how does the GUI layer know what a widget and widgetcollection are? Surely I don't have to reference the DAL from the GUI, that negates the whole point.
Firstly, I dont think this is an embarrasingly basic n-tier question.
It is a very interesting subject and one I attempted to stimulate discussion for in the old Subsonic Forums.
I share your reluctance to expose my GUI layer to the DAL.
My GUI layer only talks to BLL using the vocabulary and topics of my own Entity Model and only returns my own entities or lists or in some cases Data Tables.
My BLL only talks to a MAPping layer which maps Fetches,Saves etc to the appropriate DAL CRUD methods and converts the returned Subsonic types to my Entity types.
In doing this I was suprised at how much of Subsonic I had to duplicate and at times I felt I was going down the wrong road, I am feeling more comfortable with it now, though it still needs refactoring and refining.
For example, finding a flexible, generic means of indicating to my BLL which row(s) I wanted returned in a fetch was a challenge I hadn't expected and I finished up writing a generic queryClass with fluent interface which looks a lot like a Subsonic Select.
FWIW, I think you are headed down the right track, I guess what you have to do though is decide how you want to define those Subsonic types to your GUI.
Rob has an interesting discussion you may be interested in.
(using SubSonic 2.x) In my BLL classes I have a property which gives an object reference to the relevant DAL class. My UI form has a reference to the BLL class, so from the form I can address the DAL properties and methods via .BLL.DAL.xxxx
FWIW, I have never managed to successfully bind a SubSonic collection to a DataGridView. As alternatives, I sometimes use the collections .ToTable() method to create a DataTable and then bind to that, or alternatively I manually bind using .AddRow()
Look at the documentation for IBindingList Interface in MSDN, it has a pretty good sample.
Create, for example, a CustomersList class in your model that uses a Customer class in your BLL. Bind the grid to an instance of the CustomersList class. The presentation layer has no knowledge of the subsonic table classes.
You probably need to use an Interface. You can easily create an interface based off of the Widget in your Dal(right click on the class and create an Interface from the class). Next take the Interface and add it to your Business Logic Layer or a seperate project just for interfaces. Once you have done that you can add a reference to the Interface both in the DAL and in the GUI. This can also help if you ever change your data storage from a Database to XML etc. etc.