I would like to know, wheter it is a good idea and doesn't breaks n-tiered pattern, if I make the DAL return IQueryable - Collections and then use Linq in the BLL to do my queries?
What is about n-tiered then? Does that mean, that all my entities are fetched from databased an then queried in memory?... that would be awesome...
It depends on your UnitOfWork implementation. Use Nhibernate LINQ, and make sure the Session is not closed every time you do a LINQ operation on the IQueryable that is returned from your DAL.
Related
I am going to implement repository pattern to my project using Node.js, I am new to DDD, but I have read a lot of it. I understand repository pattern should be keep simple and deals with aggregate.
But I am wondering how should I load entity relations? in ORM we usually have eager loading and lazy loading. But since Nodejs retrieve data asynchronously, I think lazy loading is not possible.
Should I encapsulate eager inside the repository? or is it better if I make a parameter to define what relations to be included?
For example:
class GenericRepository {
find({ select, where, includes, orderBy }) {
// Code
}
}
If i define a method like that, isn't it like reinventing ORM function?
Please give me your opinions.
Thanks.
In DDD there is not such thing as lazy loading an Aggregate or parts of it. Before executing a command, the Aggregate must be fully loaded from the Repository. If you feel that in most cases it does not need to be fully loaded maybe your Aggregate boundaries are wrong and you have an Aggregate that is too big.
Regarding the Aggregate repositories in JavaScript, the simplest solution is to use a document database like MongoDB that persist an JavaScript object as it is, with minimum number of transformations.
For read (or display) scenarios, you can load only some attributes of the Aggregate but be careful to not break the Aggregate encapsulation as you start to depend on Aggregate internal properties.
The things are simpler (from this perspective) in CQRS architectures because the Aggregate corresponds only to the write-model and you can have any number of perfect-fitted/optimized read-models.
Use Automapper to expose OData with EF core, data model,
Customer, one to many relation to Order
Order
The Customer class has a ICollection of Order. Used Automapper queryable extension ProjectTo. All works fine.
However, looking at queries sent by EF to SQL, it always sending the queries to the Order even when there is no extend in the OData request. How to correct this?
Yes, that's the default behavior. You have to explicitly tell AM what you don't want it to fetch. See here.
I have a table or tables in sqlServer. I want to take data from database and keep this table's data into objects like class, but I dont want to keep this data into dataset.
What are those ways to keep data into objects taking data from database?
How can I pass data into object but not in dataset or datatable?
ORM is what you should be looking for.
For .Net framework you can look into
Entity Framework
LINQ to SQL
NHibernate
Dapper
ORM is the solution as mentioned above.....
Better use entity frame work that is good for this purpose.......it will creates entity classes with all your tables in the database.
In short: as it is suggested in the comment, some type of ORM (Object relational mapping) will do that magic for you.
Good references on this topic are the followings:
4 Benefits of Object-Relational Mapping (ORM)
ORM mapping data to objects
DataObjects.Net - ORM Framework for RAD - Introduction
Edit: To choose the right ORM for your problem, look at this Wikipedia article
List of object-relational mapping software.
I am using NHibernate for persistence, but i read somewhere that NHibernate acts as unitofwork container. So do i need to create a separate UnitOfWork implementation. ?
Or continue with Nhibernate's unitofwork.
You don't need to create separate UoW implementation.
I suggest you to read this post: nhibernate.info
According to Martin Fowler, the Unit of Work pattern "maintains a list of objects affected by a business transaction and coordinates the writing out of changes and the resolution of concurrency problems."
Nhibernate internally already implements this pattern tracking all the objects has been modified (added,updated,deleted). You don't need to do anything because it already use this pattern itself
just to make this concept clear it is like if for each row of your resultset there is a "magic" column that says if the row has been added,updated or deleted
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.