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).
Related
I have to design a software using asp .net core which collects data from various datasources (s. picture below).
E.g. DataSource1 and DataSource2 are including product data like attributes. DataSource 3 is including the assets of those products.
I thought first of all I will collect the data from each datasource and persists them in own datasource with the defined entity below.
I have the advantage later at translating or tranforming the data to use one abstract entity.
My question which pattern should be good for this system? Repository, Pipeline,...??
Could you show me some pseudo code?
What about DI if I use interfaces but should have multiplied instances of datasources?
A pattern (or a set of patterns) should be applied to solve a specific problem/complexity.
I think the pattern the pattern you need here is Facade.
The problem that it will solve is that it will hide the complexity of the 'three data sources' for your client.
Within the Facade you would merge the data into a reasonable entity.
Additionally, you could make use of the Proxy pattern, which could give you the 'cache' functionality for the 'merged' entities, which could solve the second complexity you describe.
I am not sure I understand the idea of persisting these items into a fourth datastore, that might be an overkill - but in any case, that can also be achieved with the proxy class - it's just that the cache would be more permanent - if your domain 'allows' it.
As for Repository (pattern) - well, I believe that it's very likely that any reasonable solution that you apply that will hide the details of your data access will end up to be a an implementation of a Repository.
I wouldn't be too strict about naming the patterns and sticking to sample code in books or articles. Patterns are high level guidelines that can be adjusted to needs.
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.
I'm writing an database app in C# using SQL Server CR E 3.5 and would like to implement a Repository Pattern. I've done several searches both on Google and SO; however, I cannot find an implementation that matches my needs so I will ask the SO community directly.
The key business objects in my app are: video, actor, tag category and tag. The basic business rules are as follows:
Every tag belongs to a tag category.
A video may or may have not multiple actors and tags associated with it.
Actors and tags may or may not have multiple videos associated with them.
Here is where things get fuzzy for me:
Should I implement a video repository that includes actors, tag categories, and tags or should each of these business objects have their own repositories? Given these objects can exist independently, I'm inclined to create a repository for each one.
If each object should have its own repository, how do I relate them? For example, should the video repository include a property that queries the tag repository for matches?
I'm looking for some guidelines or best practices for setting this up. I understand the basics of the repository pattern, but I need some advice as to how to connect them together.
You should only have a repository for your aggregate roots.
I would not recommend using the repository as a way of encapsulating all your queries. Repositories are not big dumping grounds for queries - they are a specific tool for use in scenarios where DDD is most applicable. See this article for some more info: http://ayende.com/blog/3955/repository-is-the-new-singleton
There should be no need to 'connect' or 'relate' repositories.
If you want to write a query such as "Load all the tags for videos that this user has borrowed", it is probably best not to put it in the repository. This query is most likely specific to a certain case, e.g. a UI, and should be written inside or close to the class for which the query is required. The output of the query would probably be mapped to read-only Data Transfer Objects specifically created for the UI's requirement, not to your entities.
newbie here. I am trying to learn OOD/OOP and read on the net that I am not supposed convert SQL tables into classes. But I cannot find an explanation why not to do it or which tables to skip. So I made an web application based on the below diagram. It works perfectly well. But I do not use OO. Would someone please explain simply which table should not be mapped into a class and why not. Thank you for your time.
P.S. Please do not use LINQ or NHibernate, etc as I do not understand them. I just need to understand the OOD.
When designing an application in .NET (and probably most other languages), every table needed by the application becomes its own class, but you can certainly have more classes that are not mapped to table.
With your program's requirements in hand, you need to design the database layer (i.e. your tables) to persist any data you want saved in a database. Then - for a small project - each table becomes a class automatically and you can start building more classes to manage these "model" or "entity" classes. Classes mapped to tables are often called entities or models. Classes that are not mapped are just called classes.
So, in your example, you have four tables, so you will have at LEAST four model classes. You would then design additional non-model classes (as needed and makes sense) to manage your model classes appropriately through your program.
If you want to understand OOP DON'T start with the database. The fact that you are seeing everywhere the 'conversion' of tables into classes is just an unfortunate side effect of demonstrating a certain ORM (Object Relational Mapper) like Entity Framework. Those are demos for a certain library and not for OOP.
So, first things first, ignore the database. ALL of it. It's unfortunate that MS pushes that damn EF everywhere as 'look how easy you can do web apps'. An ORM is an advanced topic. You should learn the basics of OOP (with C#), that is understand what an object is compared to a class, what encapsulation , inheritance , polymorphism are and about SOLID principles (google about them, you'll find lots of articles and video presentations).
Only after you understood those, try a database and start with basic ado.net . And only after you have a clear understanding of it, go read about ORMs. In fact, before that you should read about Design Patterns a bit.
You really have to have a clear understanding of all these concepts. FOr now, I think everything is very confusing to you, because the majority of tutorials target a certain funcitonality without regard to proper application layering or responsibilities. Everything is mixed together and as a beginner,you're left with the impression that this is the way you have to do things.
Development environment is C# 3.5 with a SQL Server 2008 database and Entity Framework.
Imagine you have a class and a table called Sign which represents a physical electronic sign created by a third party which your software needs to control. You also have a class called SignDriver which takes care of actually communicating with the signs. The properties/columns of Sign represent configurable information needed by the Sign Driver to properly talk to the signs.
Everything is great and you’ve patted yourself on the back quite thoroughly. Then the need arises to talk to a different sign. However this sign works differently to the previous one and requires your Sign class and table to store additional information. Let’s say 5 new things (columns/properties) need to be stored, but, unfortunately the first type of sign does not need these 5 things. You then find when you want to control 10 of each type of sign, you have many NULL values in your table.
Your domain model grows until you have more classes like Sign, each representing a different part of your problem domain and each with a corresponding table in your database. Each class suffers the same issue of collecting the common information of its type well, but NOT catering for the specialisations of each type well at all.
You realise that the nature of your problem means that there are going to be more types of signs to control, as well as more types of your other entities to cater for. You need a more extensible model.
What would be the best way forward for a system like this??
I have discussed this at length with my collegues and would really like to know what the best way to approach a problem like this is. Especially because it seems like a problem MANY people would have faced in the past.
Below are the options we’ve come up with and some points about each:
Create n number of ‘type’ classes and table for each entity to share a 1 to 1 relationship with.
Very inheritance-y.
Most time consuming when extending.
Many tables.
Create one ‘extended properties’ table for each entity to hold key-value pairs.
Referential integrity.
Extensible.
Create one global ‘extended properties’ table to store properties for ANY entity. (schema: entityType, entityId, key, value, dataType)
Super extensible.
Cannot have referential integrity with existing tables.
Doesn’t look like Entity Framework will be able to handle this well.
What would you do and why??
Any help greatly appreciated.
Cheers.
This question touches on multiple issues of software design.
Your main issue seems to be with mapping an inheritance hierarchy to your database tables. This has been extensively analysed - see the work of Martin Fowler in his book "Patterns of Enterprise Architecture". You can get some brief overviews here, but the book is better and should be on every OO developers shelf. Compare the "Table per subclass" and "Table per class hierarchy" patterns.
Some general advice: be careful of too much inheritance - favour composition over inheritance. You can almost always refactor to avoid inheritance. Basically you end up with your 'specialisations' decoupled from the Sign class, which then gives you a way forward in terms of creating a table hierarchy. As mentioned, the Head First Design Patterns book is a good place to start.
Also, don't be afraid to have heaps of classes and heaps of tables. Generally flexible designs favour lots of classes and tables (although of course there are downsides to doing this too - it's up to you to decide the best compromise).