I'm currently writing a data access layer for an application. The access layer makes extensive use of linq classes to return data. Currently in order to reflect data back to the database I've added a private data context member and a public save method. The code looks something like this:
private DataContext myDb;
public static MyClass GetMyClassById(int id)
{
DataContext db = new DataContext();
MyClass result = (from item in db.MyClasss
where item.id == id
select item).Single();
result.myDb = db;
return result;
}
public void Save()
{
db.SubmitChanges();
}
That's a gross over simplification but it gives the general idea. Is there a better way to handle that sort of pattern? Should I be instantiating a new data context every time i want to visit the db?
It actually doesn't matter too much. I asked Matt Warren from the LINQ to SQL team about this a while ago, and here's the reply:
There are a few reasons we implemented
IDisposable:
If application logic needs to hold
onto an entity beyond when the
DataContext is expected to be used or
valid you can enforce that contract by
calling Dispose. Deferred loaders in
that entity will still be referencing
the DataContext and will try to use it
if any code attempts to navigate the
deferred properties. These attempts
will fail. Dispose also forces the
DataContext to dump its cache of
materialized entities so that a single
cached entity will not accidentally
keep alive all entities materialized
through that DataContext, which would
otherwise cause what appears to be a
memory leak.
The logic that automatically closes
the DataContext connection can be
tricked into leaving the connection
open. The DataContext relies on the
application code enumerating all
results of a query since getting to
the end of a resultset triggers the
connection to close. If the
application uses IEnumerable's
MoveNext method instead of a foreach
statement in C# or VB, you can exit
the enumeration prematurely. If your
application experiences problems with
connections not closing and you
suspect the automatic closing behavior
is not working you can use the Dispose
pattern as a work around.
But basically you don't really need to dispose of them in most cases - and that's by design. I personally prefer to do so anyway, as it's easier to follow the rule of "dispose of everything which implements IDisposable" than to remember a load of exceptions to it - but you're unlikely to leak a resource if you do forget to dispose of it.
Treat your datacontext as a resource. And the rule of using resource says
"acquire a resource as late as
possible, release it as soon as its
safe"
DataContext is pretty lightweight and is intended for unit of work application as you are using it. I don't think that I would keep the DataContext in my object, however. You might want to look at repository patterns if you aren't going to use the designer generated code to manage your business objects. The repository pattern will allow you to work with your objects detached from the data context, then reattach them before doing updates, etc.
Personally, I'm able to live with the DBML designer generated code for the most part, with partial class implementations for my business and validation logic. I also make the designer-generated data context abstract and inherit from it to allow me to intercept things like stored-procedure and table-valued function methods that are added directly to the data context and apply business logic there.
A pattern that I've been using in ASP.NET MVC is to inject a factory class that creates appropriate data contexts as needed for units of work. Using the factory allows me to mock out the data context reasonably easy by (1) using a wrapper around the existing data context class so that it's mockable (mock the wrapper since DataContext is not easily mockable) and (2) creating Fake/Mock contexts and factories to create them. Being able to create them at will from a factory makes it so that I don't have to keep one around for long periods of time.
Related
I am currently using EF 6 to do the following. Execute a stored procedure, then bring in the data I need to use. The data is usually 30-40 rows per application run.
I then iterate over the var, object, table (whatever you would like to call it), performing similar (sometimes different) tasks on each row. It works great. I am able to create an Entity object, expose the different complex functions of it, and then create a var to iterate over.
Like:
foreach (var result in StoredProcedureResult)
{
string strFirstname = result.FirstName
string strLastName = result.LastName
//more logic goes here using those variables and interacting with another app
}
I recently thought it would be cool if I had a class solely for accessing the data. In this way, I could just reference that class, toss the corresponding connection string into my app.config, and then I can keep the two sets of logic separate. So when attempting to do the above in that structure, I get to the point at which, you can't return a var, or when I attempt to match object return type. The return type of the execution of a stored procedure is object (which I can't iterate on).
So my question is, how does one get to the above example, except, the var result, get returned from this data access class?
If I am missing something, or its not possible because I am doing this incorrectly, do let me know. It appeared right in my head.
I'm not going to describe the architecture in full. But based on your comments you can do the following (this is not the definitive nor the only way how to do it):
in your data access project you keep the DBContext class, all the code for the stored procedure call and also the class that defines the result of the SP call, let's call it class A;
in your shared layer project - I would suggest calling it Service layer - you can create a XYService class, that has a method e.g. GetListOfX that connects to the DB and calls the procedure, if needed this method can also perform some logic, but more importantly: it doesn't return class A, but returns a new class B (this one is defined in the service layer, or can be defined in yet another project - that might be the true shared/common project; as it would be just a definition of common structures it isn't really a layer);
in your application layer you work only with the method GetListOfX of the XYService and the class B, that way you don't need a reference to the data access project
In a trivial case the class B has the same properties as the class A. But depending on your needs the class B can have additional properties/functionality it can also ignore some properties of A or even combine multiple properties into one: e.g. combining the FirstName and LastName as one property called simply Name.
Basically what you are looking for is the multi-tier application architecture (usually 3-4 tier). The full extent of such approach (which includes heavy usage of concepts like interfaces and dependency injection) might not be suitable or needed based on your goals, e.g. if you are building just a small application for yourself with a couple of functions or you know there won't be any reuse of the components of the final solution, then this approach is too wasteful and you can work faster with everything in one project - you should still apply principles like SOLID, DRY and Separation of concerns.
I would like to learn more about creating a Database Entity (Connection?).
Coming from PHP/MySQL, i was creating only one connection and was reusing that over and over using a connection pool.
I noticed in MVC, I create new db entity almost every chance I get. Is this really the correct way to do so in real world example?
For example, I have a code that tells the user how many unread messages they have left on every refresh/page view. It goes like this:
public int UnreadMessages()
{
using (dbEntities db = new dbEntities())
{
return db.messages.Select(M => M.status == "Unread").Count();
}
}
On my _Layout.html, I have a line that calls this code. So, this is being executed on every request. The way I look at it, this is terrible way of doing it because I keep creating a new connection? or maybe this is the way it was supposed to be done on MVC.
Could someone please explain to me, the best way of doing this? or maybe provide some links that may help me understand this better?
P.S. I am also not too sure how db connection on MVC works. Wether 1 connection is made and a new db entity(Not a connection, rather just a call?) is created on requests or a new brand new connection is made on requests.
Two things, Entity framework uses underlying ADO.NET which supports powerful connection pooling, and connections to database are closed instantly by context. So you don't need to worry about connection pooling.
However, it is not good idea to create and destroy context every time for single operation. Ideally only one context should be created for entire lifecycle of a request. Since creating and destroying context is little costly it does affect performance at high load.
Controller has OnDispose method, and this is how you can easily implement it,
public abstract class DBController : Controller {
public MyDbContext DbContext { get; private set; }
public DBController() {
DbContext = new ...
HttpContext.Items["DbContext"] = DbContext;
}
protected override void OnDispose() {
DbContext.Dispose();
}
}
And your every Controller should be derived from DBController. And in Layout file you can use same context by retrieving HttpContext.Items["DbContext"]
This way same context will be used for entire request. And yes, for every request new context will be created. EF is not designed to be thread safe and should not be reused for different requests.
In the mvc world, views (including layout) should only use data from the model or include partial views with RenderAction() that get their models from other actions.
You ask about connections and EF though, and while opening and disposing objects frequently isn't great you need to understand that EF has its own connection pool, so if your action calls a bunch of methods that all create and dispose their own dbEntities() object, only one connection to the actual database will be used.
In my opinion, it's recommended to use using to create new instance as it will automatically close connection after the connection and dispose the instance.
If you want to use a Global variable, you need to make sure to open and close db connection in each method, then it still be fine.
However, the bad thing that you are doing is to call Database connection from your _Layout.html, that is the view, should only render the view; not to connect to DB.
Currently we have implemented a repository pattern at work. All our repositories sit behind their own interfaces and are mapped via Ninject. Our project is quite large and there are a couple quirks with this pattern I'm trying to solve.
First, there are some controllers where we need upwards of 10 to 15 repositories all in the same controller. The constructor gets rather ugly when asking for so many repositories. The second quirk reveals itself after you call methods on multiple repositories. After doing work with multiple repositories we need to call the SaveChanges method, but which repository should we call it on? Every repository has one. All repositories have the same instance of the Entity Framework data context injected so picking any random repository to call save on will work. It just seems so messy.
I looked up the "Unit Of Work" pattern and came up with a solution that I think solves both problems, but I'm not 100% confident in this solution. I created a class called DataBucket.
// Slimmed down for readability
public class DataBucket
{
private DataContext _dataContext;
public IReportsRepository ReportRepository { get; set; }
public IEmployeeRepository EmployeeRepository { get; set; }
public IDashboardRepository DashboardRepository { get; set; }
public DataBucket(DataContext dataContext,
IReportsRepository reportsRepository,
IEmployeeRepository employeeRepository,
IDashboardRepository dashboardRepository)
{
_dataContext = dataContext;
this.ReportRepository = reportsRepository;
this.EmployeeRepository = employeeRepository;
this.DashboardRepository = dashboardRepository;
}
public void SaveChanges()
{
_dataContext.SaveChanges();
}
}
This appears to solve both issues. There is now only one SaveChanges method on the data bucket itself and you only inject one object, the data bucket. You then access all the repositories as properties. The data bucket would be a little messy looking since it would be accepting ALL (easily 50 or more) of our repositories in its constructor.
The process of adding a new repository would now include: creating the interface, creating the repository, mapping the interface and repository in Ninject, and adding a property to the data bucket and populating it.
I did think of an alternative to this that would eliminate a step from above.
public class DataBucket
{
private DataContext _dataContext;
public IReportsRepository ReportRepository { get; set; }
public IEmployeeRepository EmployeeRepository { get; set; }
public IDashboardRepository DashboardRepository { get; set; }
public DataBucket(DataContext dataContext)
{
_dataContext = dataContext;
this.ReportRepository = new ReportsRepository(dataContext);
this.EmployeeRepository = new EmployeeRepository(dataContext);
this.DashboardRepository = new DashboardRepository(dataContext);
}
public void SaveChanges()
{
_dataContext.SaveChanges();
}
}
This one pretty much eliminates all the repository mappings in Ninject because they are all instantiated in the data bucket. So now the steps to adding a new repository include: Create interface, create repository, add property to data bucket and instantiate.
Can you see any flaws with this model? On the surface it seems much more convenient to consume our repositories in this way. Is this a problem that has been addressed before? If so, what is the most common and/or most efficient approach to this issue?
First, there are some controllers where we need upwards of 10 to 15 repositories all in the same controller.
Say hello to Abstract factory pattern. Instead of registering all repositories in Ninject and injecting them to controllers register just single implementation of the factory which will be able to provide any repository you need - you can even create them lazily only if the controller really needs them. Than inject the factory to controller.
Yes it also has some disadvantages - you are giving controller permission to get any repository. Is it problem for you? You can always create multiple factories for some sub systems if you need or simply expose multiple factory interfaces on single implementation. It still doesn't cover all cases but it is better than passing 15 parameters to constructor. Btw. are you sure those controllers should not be split?
Note: This is not Service provider anti-pattern.
After doing work with multiple repositories we need to call the SaveChanges method, but which repository should we call it on?
Say hello to Unit of Work pattern. Unit of Work is logical transaction in your application. It persists all changes from logical transaction together. Repository should not be responsible for persisting changes - the unit of work should be. Somebody mentioned that DbContext is implementation of Repository pattern. It is not. It is implementation of Unit of Work pattern and DbSet is implementation of Repository pattern.
What you need is central class holding the instance of the context. The context will be also passed to repositories because they need it to retrieve data but only the central class (unit of work) will offer saving changes. It can also handle database transaction if you for example need to change isolation level.
Where should be unit of work handled? That depends where your logical operation is orchestrated. If the operation is orchestrated directly in controller's actions you need to have unit of work in the action as well and call SaveChanges once all modifications are done.
If you don't care about separation of concerns too much you can even combine unit of work and factory into single class. That brings us to your DataBucket.
I think you are absolutely right to use the Unit of Work pattern in this case. Not only does this prevent you from needing a SaveChanges method on every repository, it provides you a nice way to handle transactions from within code rather than in your database itself. I included a Rollback method with my UOW so that if there was an exception I could undo any of the changes the operation had already made on my DataContext.
One thing you could do to prevent weird dependency issues would be to group related repositories on their own Unit of Work, rather than having one big DataBucket that holds every Repository you have (if that was your intent). Each UOW would only need to be accessible at the same level as the repositories it contained, and other repositories should probably not depend on other UOWs themselves (your repositories shouldn't need to use other repositories).
If wanted to be an even bigger purist of the pattern, you could also structure your UOWs to represent just that, a single Unit of Work. You define them to represent a specific operation in your domain, and provide it with the repositories required to complete that operation. Individual repositories could exist on more than one UOW, if it made sense to be used by more than one operation in your domain.
For example, a PlaceCustomerOrderUnitOfWork may need a CustomerRepository, OrderRepository, BillingRepository, and a ShippingRepository
An CreateCustomerUnitOfWork may need just a CustomerRepository. Either way, you can easily pass that dependency around to its consumers, more fine grained interfaces for your UOW can help target your testing and reduce the effort to create a mock.
The notion of every repository having a SaveChanges is flawed because calling it saves everything. It is not possible to modify part of a DataContext, you always save everything. So a central DataContext holder class is a good idea.
Alternatively, you could have a repository with generic methods that can operate on any entity type (GetTable<T>, Query<T>, ...). That would get rid of all those classes and merge them into one (basically, only DataBucket remains).
It might even be the case that you don't need repositories at all: You can inject the DataContext itself! The DataContext by itself is a repository and a full fledged data access layer. It doesn't lend itself to mocking though.
If you can do this depends on what you need the "repository" do provide.
The only issue with having that DataBucket class would be that this class needs to know about all entities and all repositories. So it sits very high in the software stack (at the top). At the same time it is being used by basically everything so it sits at the bottom, too. Wait! That is a dependency cycle over the whole codebase.
This means that everything using it and everything being used by it must sit in the same assembly.
What I have done in the past was to create child injection containers (I was using Unity) and register a data context with a ContainerControlledLifetime. So that when the repositories are instantiated, they always have the same data context injected into them. I then hang on to that data context and when my "Unit of Work" is complete, I call DataContext.SaveChanges() flushing all the changes out to the database.
This has some other advantages such as (with EF) some local caching, such that if more than one repository needs to get the same entity, only the first repository actually causes a database round trip.
It's also a nice way to "batch up" the changes and make sure they execute as a single atomic transaction.
I am looking for best practices of avoiding constructor injection overuse. For example I have Meeting entity which has few sub entities like shown below:
Meeting
MeetingContacts
MeetingAttendees
MeetingType
Address
MeetingCompanies
MeetingNotes
MeetingService class looks like below:
public class MeetingService
{
private readonly IMeetingContactRepository _meetingContactRepository;
private readonly IMeetingAttendeeRepository _meetingAttendeeRepository;
private readonly IMeetingTypeRepository _meetingTypeRepository;
private readonly IAddressRepository _addressRepository;
private readonly IMeetingCompanyRepository _meetingCompanyRepository;
private readonly IMeetingNoteRepository _meetingNoteRepository;
private readonly IMeetingRepositoy _meetingReposity;
public MeetingService(IMeetingRepositoy meetingReposity, IMeetingContactRepository meetingContactRepository, IMeetingAttendeeRepository meetingAttendeeRepository,
IMeetingTypeRepository meetingTypeRepository, IAddressRepository addressRepository,
IMeetingCompanyRepository meetingCompanyRepository, IMeetingNoteRepository meetingNoteRepository)
{
_meetingReposity = meetingReposity;
_meetingContactRepository = meetingContactRepository;
_meetingAttendeeRepository = meetingAttendeeRepository;
_meetingTypeRepository = meetingTypeRepository;
_addressRepository = addressRepository;
_meetingCompanyRepository = meetingCompanyRepository;
_meetingNoteRepository = meetingNoteRepository;
}
public void SaveMeeting(Meeting meeting)
{
meetingReposity.Save();
if(Condition1())
_meetingContactRepository.Save();
if(Condition2())
_meetingAttendeeRepository.Save();
if(Condition3())
_meetingTypeRepository.Save();
if(Condition4())
_addressRepository.Save();
if(Condition5())
_meetingCompanyRepository.Save();
if(Condition6())
_meetingNoteRepository.Save();
}
//... other methods
}
Here are just seven dependencies but real code contains much more of them. I used different techniques described in the "Dependency Injection Constructor Madness" but I have not found how to deal with repository dependencies.
Is there any way how I can reduce the number of dependencies and keep the code testable?
Constructor overuse is just a symptom - it seems you are approximating a unit of work by having a "master" class that knows about the various elements of message persistence and plugs them into the overall save.
The downside is that each repository communicates its independence of the others by exposing a dedicated Save method; this is incorrect, though, as SaveMeeting explicitly states that the repositories are not independent.
I suggest identifying or creating a type that the repositories consume; this centralizes your changes and allows you to save them from a single place. Examples include DataContext (LINQ to SQL), ISession (NHibernate), and ObjectContext (Entity Framework).
You can find more information on how the repositories might work in a previous answer of mine:
Advantage of creating a generic repository vs. specific repository for each object?
Once you have the repositories, you would identify the context in which they would act. This generally maps to a single web request: create an instance of the common unit of work at the beginning of the request and hand it to all the repositories. At the end of the request, save the changes in the unit of work, leaving the repositories free to worry about what data to access.
This neatly captures and saves everything as a single unit. This is very similar to the working copy of your source control system: you pull the current state of the system into a local context, work with it, and save the changes when you're done. You don't save each file independently - you save them all at the same time as a discrete revision.
To expand a little bit on my comment above:
Since this question is directed towards how to manage repository dependencies, I have to assume that the MeetingService is managing some sort of persistent commit. In the past, when I have seen classes like MeetingService with that many dependencies, it is clear they are doing too much. So, you have to ask yourself, "what is my transaction boundary". In other words, what is the smallest commit that you can make that means that a meeting has been successfully saved.
If the answer is that a meeting is successfully saved after a call to meetingReposity.Save(); then that is all that MeetingService should be managing (for the commit).
Everything else is, essentially, a side effect of the fact that a meeting has been saved (notice that now we are speaking in the past tense). At this point, event subscription for each of the other repositories makes more sense.
This also has the nice effect of separating the logic in all of the conditions into subscriber classes that follow SRP to handle that logic. This becomes important when the logic of when the contact repository commits goes through a change, for example.
Hope this helps.
Each of the first three answers give important suggestions and ideas for dealing with the problem in the abstract. However, I may be reading too much into your example above, but this looks like a problem of too many aggregate roots, not too many dependencies per se. This has to do with either a lack in the persistence mechanism underlying your repository injection infrastructure, or a misconfiguration of the same.
Simply, the Contacts, Attendees, Notes, &c. should be composite properties of the Meeting itself (if only as links to separately managed Contact, &c. objects/data); therefore, your persistence mechanism should be saving them automatically.
Heeding Bryan Watts' adage that "constructor overuse is just a symptom," a couple of other possibilities:
Your persistence mechanism should be handling persistence of the Meeting graph automatically, and is either misconfigured or lacks the capability to do this (all three that Bryan suggests do this, and I would add DbContext (EF 4.1+)). In this case, there should really only be one dependency--IMeetingRepositoy--and it can handle atomic saves of the meeting and its composites itself.
SaveMeeting() is saving not just links to other objects (Contacts, Attendees, &c.) but is also saving those objects as well, in which case I would have to agree with dtryon that MeetingService and SaveMeeting() are doing far more than the names imply, and his mechanism could alleviate it.
Do you really need the repository functionality to be split into that many interfaces? Do you need to mock them separately? If not, you could have fewer interfaces, with more methods.
But let's assume your class really needs that many dependencies. In that case you could:
Create a configuration object (MeetingServiceBindings) that provides all the dependencies. You could have a single configuration object per whole module, not just single service. I don't think there's anything wrong with this solution.
Use a Dependency injection tool, like NInject. It's quite simple, you can configure your dependencies in code in one place and don't need any crazy XML files.
I have a base class that declares a private non-static reference to the DataBase Handler instance (DBH).
DBH is a class we use to simplify database operations of derived classes. It contains the usual methods, like ExecuteScalar, StartTransaction among others; and it provides additional benefits in the application context, like caching and zero configuration.
Instances of derived classes use DBH to read/save its state in the database, and since their operations are not atomic, all derived classes use this transaction. Everything is going on in one place: a virtual method called InsertUpdate() declared in the base class.
Next, I have a collection (called Book) of instances of derived classes. I want to take collection updates as transaction.
I want to achieve something similar to this:
DatabaseHandler dbh = new DatabaseHandler()
t = dbh.StartTrasaction();
foreach( Type o in Book<Type> )
{
o.prop1 = ..
o.prop2 = ...
o.method1() ...
o.InsertUpdate(t); // uses its own instance of DatabaseHandler and starts its own transaction
}
dbh.EndTransaction(t);
Currently the InsertUpdate method is parameter-less. I guess I'll have to introduce an overloaded version which accepts a transaction object.
Besides solving my current issue, are there any design issues I need to know about? How can I improve this design or institute a better design?
Make sure you read this question
Personally, I usually go with "my own" implementation of a TrasactionScope like object that wacks data on to TLS with the added benefit of having a factory that allows for easy profiling and logging.
To me your current design sound fairly complex. By decoupling your raw database access code from your classes it will reduce duplication (and avoid requiring all your data access classes inherit off a base class). Defining an object as opposed to a set of static methods for DB access will ease testing (you can substitute a mock class)
Have you looked at the System.Transactions namespace? Unless you have already discounted it for some reason you may be able to leverage the built in nested transaction support provided there - e.g:
using (var scope = new TransactionScope())
{
// call a method here that uses a nested transaction
someObject.SomeMethodThatAlsoUsesATransactionScope();
scope.Complete();
}
If the updates are all happening on the same database connectino, then the nested transactions will work as expected. Each InsertUpdate() will run its own transaction, with the overall transaction on dbh being able to roll back the entire thing.