I'm coding mmorpg server emulator (hobby project) and i've stopped on writing data access layer. The thing is that i can't use ORM (performance matter). I've read a lot about Repository pattern but it seems like it does not fit well into my project because I'm gonna need methods like: (player db) GetAllByLevel(...), GetByName(...), etc.
I want my application to be database agnostic. (I'm using sql server for now but i would like to add support for mysql later)
Which data access pattern would fit into my project?
Sorry for my bad english.
Edit
One more question. I've read that repository pattern operates on the agreggate root.
I've got 3 tables player, player_friend and player_chest. Player is an agreggate root and if i'm not wrong i should create just one repository (PlayerRepository) that could have methods like: GetFriends([player id], ...), GetChest([player id], ...) and so on.
Am i right?
I've read a lot about Repository pattern but it seems like it does not fit well into my project because I'm gonna need methods like: (player db) GetAllByLevel(...), GetByName(...), etc.
On the contrary. There are a lot of faulty repository pattern examples out (typically leaky abstractions) which teach you wrong. GetAllByLevel is imho a good method since it describes the role of the method quite clear.
I've written about the repository pattern: http://blog.gauffin.org/2013/01/repository-pattern-done-right/. Do also read the abstraction link in the beginning of the article.
The thing is that i can't use ORM (performance matter).
No problem. The repository pattern is used to abstract away the data source, no matter which kind it is.
If you want to use vanilla ADO.NET you can read this blog post: http://blog.gauffin.org/2013/01/ado-net-the-right-way/
One more question. I've read that repository pattern operates on the agreggate root. I've got 3 tables player, player_friend and player_chest. Player is an agreggate root and if i'm not wrong i should create just one repository (PlayerRepository) that could have methods like: GetFriends([player id], ...), GetChest([player id], ...) and so on. Am i right?
No. I would say that Friends is a root too. Read this article about designing aggregates: http://dddcommunity.org/library/vernon_2011
Repository is the way to go. The point is that you can have multiple implementations of the same repository interface, one for sql server another one for oracle or postgresql. You don't necessarily have one generic implementation that supports all possible databases (this would be quite difficult).
The concrete implementation can use any specific features of the concrete dbms to fit your performance criteria.
Related
I am preparing a C#.Net project for our company and would like to know which design pattern is the best fit for creating all those business documents.
I have studied some of the available design patterns, to be honest I have problems in applying them to my real world problem, to get concrete here my scenario: Different types of documents have to be created, read into and maintained through windows forms and finally stored back to a database , like e.g. invoices(sales and purchase), contracts(sales and purchase), bill of lading, letter of credit, various inventory and warehouse documents, maybe later a bunch of accounting documents.
In the first place I thought factory method would do the job but I am not sure if it is the right choice for this task.
I guess it is the best approach to have a abstract class called "Document" with all the common fields (like docId, docDate, docNumber, docIssuer,etc.) as my base and then dive into the concrete creation of the desired document object.
What options are there? In case of factories: do I need to define a concrete class for each and every document and create the object(which would be simple inheritance, wouldn't it?) or how should a factory approach look like in regard to my problem?
Isn't it better to define each and every document spec (which finally would be like each and every database table field) as an own class and using builder pattern or composite pattern to assemble the desired document at runtime?
Or are there any other approaches available?
I wonder that many business-related programs have to make this decision but I could not find any prior questions on StackOverflow for this rather common issue.
As said before we are in planning phase and this issue may be considered a crucial pillar of the architecture, therefore any constructive advise would be highly appreciated.
You can use table per hierarchy as your database design, then use ORM like NHibernate or Entity Framework to construct documents (instead of using factory).
In Fowler's book "Patterns of Enterprise Application Architecture" there is no mention of persistent features of the Repository pattern. By "persistent features" I mean such features that update, save, add or delete entities. Just pure matching mechanism over a set of domain objects.
On the other side, lets take a look at Mike Hadlow's blog post named Using the IRepository pattern with LINQ to SQL. There are concrete persistent methods like insert and delete.
So how should a repository pattern be implemented? Could you guys please point me towards good "true" repository implementations. I'm getting some frustration on this topic.
Thanks in advance! Hope for your help!
A repository should just act like an in-memory collection of data. The nomenclature you choose, whether it be Add or Insert, Delete or Remove, Select or Get, is not important.
You could separate your repository into 2 interfaces, and then have a ReadOnlyRepository for getting / selecting data, and a WriteRepository for adding / updating / deleting data. It doesn't matter. What matters is that your application or business code uses the repository to interact with data as if it was already loaded into memory, so you don't have to craft SQL queries intermingled with business or application code.
Update
Since we're talking about a pattern, there is not a single "true" repository interface or implementation. There can be many different implementations that all follow a similar pattern.
NOTE: I am not an expert, so if you feel this question stupid/lame please forgive and mind your business. :)
Ok, as all video tutorials tell, create a LinqToSqlClasses item (dbml) file. drag tables and we are done here.
But in my case (or probably in all real world scenarios), we need more from our Data Access Layer than just the auto generated classes, right?
For Example: In a simple accounting software: i have a Accounts Table and a AccountingTransactions Table,
Now to get any account's ledger we need to write a pretty Lengthy sql query, same goes for trial-balance, day book, and Single Vouchers et cetera.
What can we do in DAL to optimize these queries to have best performance.
I would recommend using Entity Framework over Linq to SQL.
But in both these cases, you have the power of Linq for such queries. Plus this gives you better designer support (intellisense, strong types, compile time checking)
EF or LinqToSQL becomes the lower level DAL and on top of this you would use the Repository pattern to call your Data Objects in a loosely coupled way. You could also add special methods for certain repositories to query data in a specific way if this needs to be encapsulated.
You should search SO for the repository pattern with Entity Framework or LinqToSql, you'll find a couple of implementations.
See this answer :
Advantage of creating a generic repository vs. specific repository for each object?
I am developing an app in ASP.NET C# and came across the following scenario:
I will have to create some maintenance screens for different entities (tables)
Those entities will basically have the same behaviour within the UI: Search, GetById, Save, Create and GetAll
The entities may have different structure i.e. different properties (fields)
As I am talking about 20 plus admin screens, which design pattern I could take advantage of in order to minimize the amount of code I will have to write?
I though of the bridge pattern but I am a little confused on how to implement it ...
A little bit of the technology background I am using:
ASP.NET classic (n-tier)
LINQ to SQL and DAO objects
SQL Server 2005
For a set of admin screens that are just doing CRUD (Create, Read, Update, Delete) operations and with little in the way of business logic, I'd be quite tempted to more or less eschew design patterns and take a look at asp.net dynamic data. This is especially true if you want to minimise the amount of code you want to write.
This is not a design pattern... but I would strongly suggest using Dynamic Data. Jonathan Carter has some great articles about it: http://lostintangent.com/index.php?s=dynamic+data
If you're really just doing some basic stuff like this: Search, GetById, Save, Create and GetAll, I would recommend you use repositories. If done wrong repositories can get really bad and nasty, but if you're really primarily limited to this set of operations you've basically described a repository with that set of operations.
You'll want to look at ways in which you can extract the extra logic for example of searching so that you're not creating duplicate logic.
Repositories are nice and testable as long as you make sure not to let them get out of control. I give you this warning only because I've seen far too many people create monster classes out of repositories.
The repositories work with your objects. They are basically the intermediary which handles the persistence of your data. This abstraction allows you to hide from the rest of your code how you're persisting your data. In this case the implementations of your repositories will be using LinqToSql as I believe that is what you said you were using.
There are plenty of resources explaining the repository pattern.
What you want is not a design pattern. You are looking for an ORM with scaffolding. I have used and highly recommend SubSonic - http://subsonicproject.com. You can read about its scaffolding features here: http://subsonicproject.com/web-forms-controls/the-scaffold/
I want to make a perfect custom DAL (data abstraction layer) class to use with all my projects.
I've searched the internet and found some samples for this but I never know which is the best approach.
Is it to make [Attributes]? Or use <Generics> or something else?
So please just give me a head line and I'll go on from there.
Thanks again and forgive my language.
Just make sure you:
Always use stored procedures
Never use stored procedures
Sometimes use stored procedures
Use nHibernate
Use SubSonic
Use Entity Framework
Write your own
Never write you own
Use POCO
Use ActiveRecord
Use IRepository
Always do what Fowler says
Never do what Fowler says
Don't use Linq to SQL, it's dead
Use Linq to SQL, it's no longer dead
Do all that and you will be fine.
Best approach is:
Don't do it yourself unless its for an academic research project or you intend to build a business shipping ORMs.
Try out the dozens of existing ORM solutions first. (Entity framework, subsonic, nhibernate etc etc...). They all have their quirks and limitations mixed in with tons of awesomeness.
ORMs are incredibly hard to get right and a huge undertaking.
Slightly related and on the money: http://wekeroad.com/2009/06/11/youre-not-your-data-access/
I can recommend you to read this article first. And take a look at EnterPrise Library's Data Access Application Block.
If you are a starter I would recommend use of SubSonic (more so if you are on web development).
as also one mentioned, don't try to implement a ORM tool yourself, there are a lot of them freely available. But a DAL isn't a ORM tool, the ORM tool will be used within your DAL. The DAL is just for hiding the data access logic from the rest of your app in order to have a more maintainable solution. In the end you could also have normal SQL statements i. your DAO class. What you should pay attention at when creating your DAL is to decouple it as much as possible from the rest of the app/other layers. This can be achieved by coding against interfaces and by using dependency injection. Spring is a great help here (given you program in Java). Beside that, there is no big magic on building such a layer.
Trying to create the ulimate, best, perfect DAL seems a bit crazy - there are so many different application scenarios with different and competing requirements and needs that I don't believe anyone can come up with THE ONE ultimate DAL.
You need to check out some of the existing ORM tools, get to know one or two of them, know their strengths and possibly drawbacks, and then be able to pick the best one for every given situation. I doubt it'll always be the same.....
SubSonic is great for smaller, nimbler projects - as is Linq-to-SQL, as long as you use SQL Server as your backend. If you need more enterprise power, you should look at NHibernate, ADO.NET Entity Framework, or other bigger, more capable players (which are just too complex and ill suited for a small, simple scenario).
I don't think there's THE perfect way to create a DAL - learn what's available, learn how to choose the one best suited to your current need, and don't reinvent yourself - use what's available out there!
Marc
Please read Data Access Layer Design Considerations
Definitely don't write your own persistence manager. You should use an Object-Relational Mapper (ORM) if you want to start from a class structure and have the ORM generate the SQL table structures for you, or use an SQL Mapper if you want to start from SQL tables and want to have your classes represent table rows.
I've had great experience using the iBatis SQL Mapper, and a lot of people like Hibernate for an ORM (though there's a learning curve).
Martin Fowler describes several good approaches for writing data access layers in Patterns of Enterprise Application Architecture (here's a catalog).
For instance, iBatis for .NET uses Fowler's Table Data Gateway pattern. In iBatis you specify Table Data Gateway objects in XML. Each Gateway typically governs access to one SQL table, although you can do multi-table operations too. A Gateway is composed of SQL statements, each wrapped in a bit of XML. Each SELECT returns one or more row objects, which are just sets of attributes plus getter and setter methods (in .NET these are called POCOs or PONOs, Plain Old C# Objects or Plain Old .NET Objects.). Each INSERT or UPDATE takes a POCO as its input. This seemed pretty intuitive, and not too hard to learn.
Linq to SQL is the best solution or you can try da easiest solution http://fluentado.codeplex.com/