public int val { get; set construct; }
public int val { get; set; }
Both can be 'publicly' read, 'publicly' written, and written in constructor... Are the two equal?
This has something to do with GObject style construction.
The parameter is installed using the G_PARAM_CONSTRUCT ParamFlag when construct is specified.
I haven't looked deeper into properties yet, but as I understand it so far it means that the property is set early in the construction process when this flag is set.
There is also a G_PARAM_CONSTRUCT_ONLY flag that allows the property to be set only at construction time. I don't know if Vala has support for this though.
It's mentioned in the Object Construction topic of the GObject manual.
Related
maybe my question can seem very silly, but i am a beginner and i am doing an exercise from a book about MVC and ASP.NET.
I don't understand the meaning of the second rows:
[LargerThanValidationAttribute(18)]
public VoterAge { get; set; }
because i see that VolterAge has not a type, and i read the message from VS that VolterAge doesn't exist in this context, and i don't understand the meaning of it. What have i to use for VolterAge? A field in a DataBase? What type of data is it?
Thank you to all.
P.S. LargerThanValidationAttribute is an extension of ValidationAttribute.
You're definitely missing a type in that property declaration.
At a guess, given it's 'VoterAge' and by the value supplied in the LargerThanValidationAttribute I would say it's missing int
It should be
[LargerThanValidationAttribute(18)]
public int VoterAge { get; set; }
This declares that property to be of type int
I am attempting to create Web API controller in F# which returns objects from Entity Framework. SharpObject and SharpContext are my object and DbContext respectively defined in a c# project.
/// Retrieves values.
[<RoutePrefix("api2/values")>]
type ValuesController() =
inherit ApiController()
let values = [| "value1"; "value2" |]
/// Gets all values.
[<Route("")>]
member x.Get() : IEnumerable<SharpObject> =
use context = new SharpContext()
context.SharpObjects.ToList() :> IEnumerable<SharpObject>
Here is SharpObject with the SerializableAttribute.
[Serializable]
public class SharpObject
{
[Key]
public virtual int Id { get; set; }
public virtual string Description { get; set; }
}
The error that I am getting is this:
The type System.Data.Entity.DynamicProxies.SharpObject_3A697B5C46C0BF76858FEAFC93BFED36DD8D4CA2CEACBB178D2D3C38BB2D2052 was not expected. Use the XmlInclude or SoapInclude attribute to specify types that are not known statically.
When I de-compile this using ILSpy, it looks like this:
[Route("")]
public IEnumerable<SharpObject> Get()
{
SharpContext context = new SharpContext();
IEnumerable<SharpObject> result;
try
{
result = (IEnumerable<SharpObject>)context.SharpObjects.ToList<SharpObject>();
}
finally
{
IDisposable disposable = context as IDisposable;
if (disposable != null)
{
disposable.Dispose();
}
}
return result;
}
What is the best way to get my list to show through in f#?
This happens because the object that you get from EF is not, in fact, of type SharpObject, but rather of that scarily named type, which inherits from SharpObject. This type is called "proxy" and is dynamically generated by EF in order to provide certain services (such as lazy loading, see below).
Because your action is declared as returning IEnumerable<SharpObject>, the default WebAPI's XML serializer expects to find object of that type, and so rightly complains upon finding an object of different type.
One temporary, bandaid-style fix that you can try is to remove the virtual keywords from your entity (why do you have them there, anyway?). It is the presence of the virtual keywords that causes EF to generate the proxy type. Absent virtual, no proxy will be generated, thus making the XML serializer happy.
This, however, will not work once you extend your model to include navigation properties with lazy loading. Those properties, you must make virtual, otherwise lazy loading won't work.
So the correct fix is not to use the same type for both DB-facing DTO and client-facing DTO. Use different types.
Using the same type for these two purposes may seem "convenient" at first, but this road quickly leads to numerous problems. One of small technical problems you have already discovered. But even absent those, conceptually, you almost never, ever want to just serve up your DB records directly to the untrusted user. Some of possible consequences include security holes, badly factored UI code, badly factored database structure, performance problems, and so on.
Bad idea. Don't do it.
P.S. This doesn't actually have anything to do with F#.
I have a StructureMap config that looks something like:
cfg.For<ICacheOrder>().Use<CacheOrder>().Ctor<int>().Is(context => LoginHelper.LoginID);
cfg.For<ICacheProduct>().Use<CacheProduct>().Ctor<int>().Is(context => LoginHelper.LoginID);
cfg.For<ISQLOrder>().Use<SQLOrder>().Ctor<int>().Is(context => LoginHelper.LoginID);
cfg.For<ISQLProduct>().Use<SQLProduct>().Ctor<int>().Is(context => LoginHelper.LoginID);
Via constructor injection, a chain of objects can be created, with some needing an int LoginID that is determined at the time of creation. The static LoginHelper determines the LoginID.
Presently in my config, LoginHelper is called for every created object. Is there a way, perhaps via StructureMap's IContext, for LoginID to be "remembered" and only determined once within a chain of creation?
I know that I could refactor and create an ILogin interface/concrete that StructureMap could construct and cache - but I'd prefer my various layers to be concerned only with a simple int LoginID.
Although it's okay to inject primitive configuration values in your services, when you repetitively inject that same primitive into multiple services, you are missing an abstraction.
This is clearly the case with your configuration; you are missing an abstraction.
The solution is to let those services depend on an abstraction rather than a primitive value. For instance:
public interface ICurrentUser
{
int LoginID { get; }
}
And you can create a rather simple implementation as follows:
public class CurrentUserImpl : ICurrentUser
{
public CurrentUserImpl()
{
this.LoginID = LoginHelper.LoginID;
}
public int LoginID { get; private set; }
}
This means that you will have to change the constructors of CacheOrder, CacheProduct, SQLOrder and SQLProduct, but when you do this, your configuration gets much more maintainable:
cfg.For<ICacheOrder>().Use<CacheOrder>();
cfg.For<ICacheProduct>().Use<CacheProduct>();
cfg.For<ISQLOrder>().Use<SQLOrder>();
cfg.For<ISQLProduct>().Use<SQLProduct>();
The problem of "remembering a param literal" now goes away immediately, because we can now register the ICurrentUser as follows:
cfg.For<ICurrentUser>().Use<CurrentUserImpl>();
The default lifecycle in Structure Map is per request (per object graph) so the same instance is injected into all objects in a single object graph.
Another option is to register it using the HttpContext lifecycle, but this of course only works when running an ASP.NET web application.
What is the equivalent of g_param_spec_boxed() in Vala?
These functions are not bound. It wouldn't be a big deal to bind them, so you can request them by reporting a bug.
Anyway, unless you're doing something at run-time, you should use Vala properties such as:
public class Foo {
public YourStruct your_struct { get; set; }
}
Which will create a property named your_struct for the boxed type YourStruct.
Using interfaces is a very easy way to remove dependencies, but what happens when one of your classes needs a method not defined by the interface? If you're using constructor injection or a factory, how do you access that extra method without casting? Is this possible?
Here is an example of a factory with this problem. Am I trying to do something impossible? Thanks for your help.
interface IFoo {
int X { get; set; }
int Y { get; set; }
}
public class A : IFoo {
int X { get; set; }
int Y { get; set; }
}
public class B : IFoo {
int X { get; set; }
int Y { get; set; }
int Z { get; set; }
}
public static class FooFactory {
public static IFoo GetFoo(string AorB) {
IFoo result = null;
switch (AorB) {
case "A":
result = new A();
break;
case "B":
result = new B();
break;
}
return result;
}
}
public class FooContainer {
private IFoo foo;
public FooContainer(IFoo foo) {
this.foo = foo;
}
/* What methods would you define here. I'm new to IoC. */
}
public class Main(...) {
int x,y,z;
IFoo fooA = FooFactory.GetFoo("A");
x = foo.X;
y = foo.Y;
IFoo fooB = FooFactory.GetFoo("B");
x = foo.X;
y = foo.Y;
z = foo.Z; /* Does not compile */
z = ((B)foo).Z; /* Compiles, but adds unwanted dependency */
}
You do indeed need to cast. This is normal, and sometimes necessary. It is usually a sign that something is wrong though.
The ideal is that if a method/routine takes/returns an interface, then your logic only cares about the members exposed by that interface. If inside that method you find yourself checking the exact type so that you can cast to that type and call different members depending on the type, then something probably be wrong.
Let's say you have an IContact interface, and some of your entities that implement this are your classes Customer, Purchaser, and Contractor. If you have a SendChristmasCard method that takes IContact, it should only care about the IContact members. If you have logic inside this method that is doing a select Case on the obj.GetType().ToString to find out if it's a Customer or not, then:
That functionality should probably be over in the Customer-centric side of your code base, taking a Customer object as a parameter. (In your example, there would be separate logic for acting upon class A and class B.)
IContact should define common members that your SendChristmasCard method would call, and be completely ignorant of the logic that goes on inside the particular object. Each class that implements IContact would implement these member differently. (In your example, class A would also implement property B, but it wouldn't do anything with it.)
In the case where a method returns an interface and you use the object, the above still applies but in my experience it can, now and then, be best to put up with the casting. The complication you add by "fixing" the situation might make it more complicated. I would say that the further up and non-standard the logic is, just take the simple way out. SendChristmasCard is obviously not core functionality; and if an IContact factory method is only handy method that gives you All the contacts, then maybe just use that, pass it to SendChristmassCard(IContact Contact), and inside there check for the type to say "it was great buying from you this year" or "it was great selling to you this year" etc. But if this is core logic in your system, you really need to look for a better way.
Check out the Decorator Pattern though, which can help in situations like this.
When you encounter the need to downcast an object, it is usually a sign that the API could be better.
Downcasting an abstract type is a violation of the Liskov Substitution Principle. It can usually best be addressed by changing the style of the interface in question. Instead of exposing a lot of properties and queries (in CQS terminology), reverse the focus towards a more command-oriented approach. This is the Hollywood Principle.
Instead of having IFoo expose the X and Y properties, you may be able to redefine its behavior towards a set of commands:
public interface IFoo
{
void DoStuff();
void DoSomethingElse(string bar);
void DoIt(DateTime now);
}
Concrete implementations can then encapsulate whatever data they would like (such as X, Y or Z properties) without the consumer needing to know about them.
When the interface grows to become too big, it's time to apply the Interface Segregation Principle or the Single Responsibility Principle.
If you're trying to access a method that isn't available to the interface, then don't use the Factory. You're obviously hard coding a dependency...so just go with it (but only if it's really necessary).
No need to over-complicate things.
Trying to cast back to an Object type rather than the interface is going to introduce a dependency...but it's going to hide it rather than obviously expose the dependency. If somebody changes the Factory in the future and your call returns a different Object type, your code is now going to break in a non-obvious way.