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.
Related
I creating a little modular asp.net MVC application. I am using dynamic entity framework for adding a entity model to dbcontext:
i have a category entity and i want to use this entity in different project in one solution. when i running application i see this error:
The type 'Module.Pages.Models.Category' and the type 'Module.Menus.Models.Category' both have the same simple name of 'Category' and so cannot be used in the same model. All types in a given model must have unique simple names. Use 'NotMappedAttribute' or call Ignore in the Code First fluent API to explicitly exclude a property or type from the model
I really have two questions:
What is the difference between an Entity Framework Entity object and an ADO.NET C# POCO Entity.
Do I have updating a record using a repository correct below?
If you turn off code generation, then add the ADO.NET C# POCO Entity Generator, it provides a nice class representation of your Entity Framework 4 objects. The idea is that (from here):
The POCO Template can be used to generate persistence ignorant entity types
from an Entity Data Model.
However, these objects have the relations between objects as well as a link back to the database. For example, you can pull one out of your repository, alter it, then save changes at the repository or unit of work level, and it saves the content to the database.
So my question is what is different between a native Entity Framework object and these POCOs generated using this tool?
This is what I think when I update a record using a repository. Is this wrong?
Request a POCO from the repository.
The Repository loads the records from the data context, creates a new POCO for each record found, copies the values from the Entity Framework objects to the POCOs, and returns a collection of the new POCOs.
Changes are made to these POCOs outside of the repository, then the POCOs are submitted back to the repository using something like Save(POCO).
The repository loads the matching records from the database and copies the POCO properties to the Entity Framework objects.
One calls Save using either the repository object or unit of work object.
In case of POCO generator the generated entity classes (eg, Employee, Company etc.) don't derive from any special class (hence called Plain Old).
Whereas in case of entityobject generator, the entity classes derive from the special 'EntityObject' class, which provides certain capabilities.
The objective behind having POCO classes is to do away with the DB specific concerns of an entity. Thus keeping our domain model unaware of DB/persistence operations.
POCO means that you have a plain old CLR class which is not polluted by special constructs related to the persistance. Entity objects are derived from EntityObject class and they use a lot of classes and attributes directly related to entity framework. When using EntityObjects you are making your code fully dependent on entity framework.
What you describe in your repository was used in EFv1 to achieve POCO approach. Currently you can use POCOs directly. POCOs don't have any relation to the database. In some scenarios POCOs are dynamically proxied by EF dependent constructs but this happens during runtime so it doesn't pollute your code.
Given an Entity Data Model (EDMX) with "Code Generation Strategy" set to "None", how does EF determine which CLR types to map the conceptual model to?
I think I read somewhere that it just probes the assembly for types that match the conceptual model, but that was in reference to a CTP edition of EF. Is this still the case?
Can I control this process somehow?
In particular, I am in a scenario where I am moving a substantial codebase from using Linq2SQL to using POCO with EF 4.0. Thus, I have the Linq2SQL classes as well as my POCO classes, for now residing in the same assembly, but in different namespaces. I'm trying to have a smooth migration from L2S to EF so I would like to have the two frameworks run in parallel for a while. However, I get a runtime-error saying
The mapping of CLR type to EDM type is
ambiguous because multiple CLR types
match the EDM type 'SomeType'.
Previously found CLR type
'SomeNamespace.SomeType', newly found
CLR type 'SomeNamespace.POCO.SomeType'
where SomeNamespace is the namespace of the L2S entities. This error makes sense if EF is just probing for all types matching the conceptual model. Can I confine EF to only probe the SomeNamespace.POCO namespace? Or should I put my POCO objects in another assembly? Or should I take a third approach?
Thank you.
Notice this comment from the ADO.NET team blog:
Jeff 25 Feb 2010 9:10 AM #Derek
This is intentional. You can put your
POCO classes in whatever namespace
you'd like. The Entity Framework's by
convention mechanism for detecting
which properties on the entity match
the properties of entities in your
model does not use Namespace. What
matters is that the type name (without
namespace) matches the EntityType name
in your model (edmx/csdl file).
One area to watch out for is if you
have multiple types with the same name
but in different namespaces. Because
we don't account for namespace, we
detect that we've found multiple types
and we throw an exception.
Jeff
See this article:
link text
I've been learning the ASP.NET MVC framework using the Apress book "Pro ASP.NET MVC Framework" by Steven Sanderson. To that end I have been trying out a few things on a project that I am not that familar with but are things that I thing I should be doing, namely:
Using repository pattern to access my database and populate my domain/business objects.
Use an interface for the repository so it can be mocked in a test project.
Use inversion of control to create my controllers
I have an MVC web app, domain library, test library.
In my database my domain items have an Id represented as an int identity column. In my domain classes the setter is internal so only the repository can set it.
So my quandries/problems are:
Effectively all classes in the domain library can set the Id property, not good for OOP as they should be read-only.
In my test library I create a fake repository. However since it's a different assembly I can't set the Id properties on classes.
What do others do when using a database data store? I imagine that many use an integer Id as unique identifier in the database and would then need to set it the object but not by anything else.
Can't you set your objects' IDs during construction and make them read-only, rather than setting IDs through a setter method?
Or do you need to set the ID at other times. If that's the case, could you explain why?
EDIT:
Would it be possible to divorce the ID and the domain object? Does anything other than the repository need to know the ID?
Remove the ID field from your domain object, and have your repository implementations track object IDs using a private Dictionary. That way anyone can create instances of your domain objects, but they can't do silly things with the IDs.
That way, the IDs of the domain objects are whatever the repository implementation decides they are - they could be ints from a database, urls, or file names.
If someone creates a new domain object outside of the repository and say, tried to save it to your repository, you can look up the ID of the object and save it as appropriate. If the ID isn't there, you can either throw an exception to say you need to create the object using a repository method, or create a new ID for it.
Is there anything that would stop you from using this pattern?
you can use the InternalsVisibleTo attribute. It will allow the types from an assembly to be visible from the tests (provided they are in different assemblies).
Otherwise you can leave the property read-only for the external objects but in the same time have a constructor which has an ID parameter and sets the ID property. Then you can call that constructor.
Hope this helps.
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'.