I want to replace ORMLite to EF5, and please don't ask me why :P ... So I searched around the net and have no luck finding much information on how to actually do this.
Do I need to rewrite ORMLiteConnectionFactory into EFConnectionFactory that registers in global.asax.cs? It seems like a lot to implement and very complex because it is linked to IOrmLiteDialectProvider OrmLiteConfig and all that, and it doesn't seem right because SS normally have a simple answer to all questions. For example, it is rather easy if I want to change Funq to another DI provider.
Is ORMLite the fixed choice of weapon or is this a flexible option that I can tune? Please help.
For all intents and purposes you're better off pretending OrmLite doesn't exist. OrmLite simply provides extension methods off ADO.NET's raw IDbConnection interfaces which works similar to (and why it is able to be used alongside with) Dapper and other Micro ORMS.
Entity Framework in contrast manages its own heavy abstraction that's by design not substitutable with other Micro ORMS, so you shouldn't attempt this route.
Simply ignore OrmLite exists and use Entity Framework as you normally would. Last I heard EF doesn't play too nicely with IOCs so you probably have to resort to the normal case of instantiating a new EF DataContext whenever you want to use it.
Related
Hybris tell us that Converters should use populators and not vice versa because can be critical for performance considerations.
But when I am digging in hybris code you can see populators like DefaultAbstractOrderEntryPopulator, ProductFeatureListPopulator which
are wiring converters.And I have also find Populators using other populators such as ProductPopulator.
I read the following links but I cannot find anything about using a converter inside a populator or populator inside of populators:
Wiki Hybris - Converters and Populators
Wiki Hybris - DTOS best practice
Wiki Hybris 6
so, can we use converters inside populator like Hybris does? and populators inside populators?
I would like to give my point of view to answer this question. One common mistake when working with converters and populators is to confuse them.
Converters creates a DTO and populators filling the DTO.
We have to be very careful when we are going to use a converter inside of a populator and to be completely sure that
we need to do that.
If we have a long chain of populators using converters we can have a performance risk. For instance
C1->P1->C2->P2->C3->P3....
I think the best practise to follow is:
1) Be aware of the converters are already done, and ckeck if we have to add our populator to an existing Converter
(for example using the modifyPopulatorList)
2) If our DTO has another dependency with other DTO
We should ask ourselves if that dependency it is really necessary.I will decide this according to if that second DTO is used in many places
or not.Because if you are the only one who use it maybe you can merge the properties in only one DTO and avoid to have two different converters.
3) Other possibility It is to use differents converter in parallel as we can see in
WIKI HYBRIS - Facades and DTOs
To sum up, the design of our converters and populators is our responsability, and we have to get the best design posible of them to avoid
performance problems.
Basically the way to do it is: never write a concrete converter class and never call a populator directly.
But this is how the product is built for extensibility and frankly you can do whatever you like.
I am learning unit of work at google.
But most of the example I get is about with unit of work with DbContext.
So please could anyone give me example of Unit of work with ObjectContext.
[Just my thinking, May be not correct.]
I don't like code first pattern because it need me to write properties classes(with get set methods) myself.
But by using edmx file with objectContext, i don't need to create properties classes which take time.
There are plenty of articles on this.
Entity Framework POCO (EF4): Generic Repository and Unit of Work
Prototype
Entity Framework 4 POCO, Repository and Specification Pattern
These abstractions may not fit to your problem exactly. So understand the concepts behind the Entity Framework before going into making abstractions.
I'm facing several problems trying to apply DDD with EF4 (in ASP MVC2 context). Your advaice would be greatly appreciated.
First of all, I started to use POCO because the dependacy on ObjectContext was not very comfortable in many situations.
Going to POCO solved some problems but the experience is not what I was used to with NHibernate.
I would like to know if it's possible to use designer and to generate not only entities but also a Value Objects (ComplexType?). If I mean Value Object is a class with one ctor without any set properties (T4 modification needed ?).
The only way I found to add behavior to anemic entities is to create partial classes that extends those generated by edmx. I'm not satisfied with this approach.
I don't know how to create several repositories with one edmx. For now I'm using a partial classes to group methods for each aggregate. Each group is a repository in fact.
The last question is about IQueryable. Should it be exposed outside the repository ? If I refer to the ble book, the repository should be a unit of execution and shouldn't expose something like IQueryable. What do you think ?
Thanks for your help.
Thomas
It's fine to use POCOs, but note that EntityObject doesn't require an ObjectContext.
Yes, Complex Types are value objects and yes, you can generate them in the designer. Select several properties of an entity, right click, and choose refactor into complex type.
I strongly recommend putting business methods in their own types, not on entities. "Anemic" types can be a problem if you must maintain them, but when they're codegened they're hardly a maintenance problem. Making business logic separate from entity types allows your business rules and your data model to evolve independently. Yes, you must use partial classes if you must mix these concerns, but I don't believe that separating your model and your rules is a bad thing.
I think that repositories should expose IQueryable, but you can make a good case that domain services should not. People often try to build their repositories into domain services, but remember that the repository exists only to abstract away persistence. Concerns like security should be in domain services, and you can make the case that having IQueryable there gives too much power to the consumer.
I think it's OK to expose IQueryable outside of the repository, only because not doing so could be unnecessarily restrictive. If you only expose data via methods like GetPeopleByBirthday and GetPeopleByLastName, what happens when somebody goes to search for a person by last name and birthday? Do you pull in all the people with the last name "Smith" and do a linear search for the birthday you want, or do you create a new method GetPeopleByBirthdayAndLastName? What about the poor hapless fellow who has to implement a QBE form?
Back when the only way to make ad hoc queries against the domain was to generate SQL, the only way to keep yourself safe was to offer just specific methods to retrieve and change data. Now that we have LINQ, though, there's no reason to keep the handcuffs on. Anybody can submit a query and you can execute it safely without concern.
Of course, you could be concerned that a user might be able to view another's data, but that's easy to mitigate because you can restrict what data you give out. For example:
public IQueryable<Content> Content
{
get { return Content.Where(c => c.UserId == this.UserId); }
}
This will make sure that the only Content rows that the user can get are those that have his UserId.
If your concern is the load on the database, you could do things like examine query expressions for table scans (accessing tables without Where clauses or with no indexed columns in the Where clause). Granted, that's non-trivial, and I wouldn't recommend it.
It's been some time since I asked that question and had a chance to do it on my own.
I don't think it's a good practice to expose IQueryable at all outside the DAL layer. It brings more problems that it solves. I'm talking about large MVC applications. First of all the refactorings is harder, many developers user IQueryable instances from the views and after struggle with the fact that when resolving IQueryable the connection was already disposed. Performance problems because all the database is often queried for a given set of resultats and so on.
I rather expose Ienumerable from my repositories and believe me, it saves me many troubles.
Im new to subsonic and generally this was of programming, i usually develop from a rad perspective so using the visual studio dataset designer, but i wanted to start looking at developing n teir approach.
Ive never used a business logic layer, (naughy) normally my code behind takes care of validation so to speak aswell as general page level validation.
How can i generate my business logic, do i create a partial class of one of my classes and then add the business logic into this? and how would this look? just so i have an idea.
Any exmaples or advice would be greatly appreciated.
Thanks
Dan
The big gotchya with SubSonic is that it generates classes from database tables, there is a 1-to-1 correspondence between the two. That makes the classes SubSonic generates quite unsuitable for use as business objects, because it would tie your business layer very directly to your database structure. This is a bad thing (in nearly all scenarios that come to my mind, anyway).
SubSonic is a query tool and little more. It most certainly is not an ORM.
With that in mind, I believe the correct way to create a Business Logic Layer is to write your own business classes, and write Repository classes to manage loading and storing the data. But use SubSonic only internally to the Repository classes to handle the actual persisting of your data to the database.
If you use the SubSonic generated classes throughout your project you will find you are most likely doing it wrong, and the first significant change to your DB schema will illustrate that nicely (or .. not nicely).
In fact, I would recommend quickly moving into learning a real ORM like NHibernate or Entity Framework. They bring you much farther down the Happy Path, whereas SubSonic still requires one to do much of the Data Layer implementation themselves.
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.