I would like to extend the types generated by the LinqToSQL TypeProvider with additional members. Is this possible? For example if the TypeProvider is pointed to a DB with a table called Company it will expose a type Company with access to the columns. As an example can I a member Company.employees to the generated type which will return all current employees from the employees table?
I don't see why you could not.. provided you have the source for the type provider!
That said, creating or extending a type provider, while not being overly complicated, is not trivial either.
So depending on how central this type generation aspect is for you, it might be best to use existing type providers, and build a layer on top of them on the 'client side'.
Once you have refined a compelling scenario where this would really yield value, then you can reuse this layer anyway.
What is your end-scenario ?
Doesn't the existing SQL Type provider cover the Company.employees case ?
It sounds like what you want to do could be accomplished by using a type extension.
Type extensions can be added to any accessible type, which should include types generated by the type provider.
Related
I am working on a patch for a firebird rails adapter. My goal is to make it possible to define a column as the type boolean if the domain of the column has a defined name.
I found the SqlTypeMetadata class which I am using to create FirebirdColumns in the method fetch_type_metadata in the module SchemaStatements.
But it seems that this is used only after the data is fetched so it doesn't use the defined true/false values in the query. So, right now, I am looking for a way to tell ActiveRecord the type of a column on an adapter basis. I read the files schema_definitions and schema_statements several times in case I am missing something but I couldn't find a method there... .
Where is a method that I can overwrite to make the typecasting correct?
Firebird doesn't communicate information about the domain of a column in the bind information of a prepared query. It only communicates the basic underlying datatype information. So if you have defined a domain X with underlying type CHAR(1), then Firebird will communicate it as a CHAR(1), not as X.
There is no option to obtain the domain, except by querying the metadata tables for additional information. So, what you want to achieve is either not possible, or at least it will be complicated.
I am trying to create a OData service that returns user parameters found in the databasde usr05. Those can be accessed by the ABAP statement:
GET PARAMETER ID 'XXX' FIELD YYY.
This means, that basically do not need a key value.
In SEGW it is impossible to create an entity type without one though.
The solution of course could be a dummy key field, that is simply ignored in the backend implementation.
Does anyone know a better solution?
Thanks in advance,
Eric
it is not a shame it is by design and follows the OData specification.
Every entity type must have a key.
What you can try to use instead is to use a property that is based on a so called complex type within an entity type that is used for your users.
The latter should have a key.
Like the complex type address that is used in the entity type Supplier
https://services.odata.org/OData/OData.svc/$metadata
I'm currently working on a OData Service(SAP Gateway), wherein the entity types are generated during the runtime. I know, that this wouldn't be as per the OData best practices, where the entity types should be static and is part of the design phase.
Questions:
1. With the request for metadata, all the entity types are generated in a method called DEFINE(provided by SAP Gateway framework). I'd like to separate the generation of each entity type, as the information required for the generation is different for each entity type. Later on, new entity types will be added, which would have a further set of instructions for the generation.
Is the Strategy pattern best for this? With this, the generation of different entity types are separated. If Strategy, then, should the Factory method return all the concrete strategies at once and let the context loop through all the strategies to generate the entity types?
Or is there any other design approach for this?
Thanks a lot in advance!
The entity types are defined in method DEFINE. The definition is nothing but creation of entity type based on a defined data structure. The code required to create entity types varies for each entity type. With runtime, I mean, the code written as the definition of entity type, is executed to form an entity type during the request for metada.
I was going to implement a custom DisplayAttribute in order to allow dynamic display values based on model values, but I can't because DisplayAttribute is sealed.
Before I go off and write my own customer attribute that emulates the behavior of DisplayAttribute, can anybody think of why this is sealed? I'm assuming there is a reason behind it, and if so, that may be the same reason I shouldn't try to "hack" around this limitation by rolling my own.
I'm not asking anyone to read Microsoft's mind, I'm just hoping someone already knows the by-design reason it's sealed, so that I can take that into account when rolling (or avoiding) my own implementation.
In general it is considered best practice to seal attributes. FxCop has a rule about it, defined here. From that page:
The .NET Framework class library provides methods for retrieving custom attributes. By default, these methods search the attribute inheritance hierarchy; for example Attribute.GetCustomAttribute searches for the specified attribute type, or any attribute type that extends the specified attribute type. Sealing the attribute eliminates the search through the inheritance hierarchy, and can improve performance.
Many of the MVC attributes (ActionFilter, etc) are unsealed because they are specifically designed to be extended, but elements in the DataAnnotations namespace are not.
Not exactly what you asked, but following your intent...
You can still allow for dynamic display values, you just wont extend the DisplayAttribute.
Instead, you can implement your own IModelMetadataProvider which could contain any logic needed to create dynamic display values.
Brad Wilson, from the ASP.NET MVC team, has a good article and sample of this on his blog: http://bradwilson.typepad.com/blog/2010/01/why-you-dont-need-modelmetadataattributes.html
I see heavy use of "store" objects in the web app I am working on. Is there a name for this pattern and would you say these types are in the BLL or DAL?
These stores contain fragments of what I would consider a classical DAL type, associated with a single type.
For example, we have a TabStore containing methods for the persistance and retrieval of Tabs. Within each method in the TabStore there is code to invoke the appropriate NHibernate query.
What are the pitfalls (if any) of working with this pattern? Is it really a simple attempt to separate what might once have been a monolithic Dal type into more manageable, smaller types?
Example method:
public IList<Tab> GetAllTabInstancesForUserId(Guid userId)
{
IList<Tab> tabInstances =
UoW.Session.CreateQuery("from Tab t where t.UserId=:userId order by t.TabOrder")
.SetGuid("userId", userId)
.SetCacheable(true)
.List<Tab>();
return tabInstances;
}
It may be what is more commonly known as a Repository.
The abstract Repository belongs in the Domain Model, but should be implemented by concrete classes in a separate Data Access Component.
If I understand the question correctly, "stores" are more related to DAL than to BLL, since there should be little logic in them - after all their role is just "storing".
Some more details would definitely be helpful, including code snippets where the 'store' is used...
But based on what you have in your question, it sounds like the developers used the term 'store' instead of 'Repository' which implies the Repository Pattern (which are related to your Data Acess Layer).
After your update...it definitely seems like what the developers originally called a 'store' is a 'repository'.