Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm running an email marketing program that runs and schedules campaigns. So I have two types of campaigns in it:
Ad hoc
Scheduled
And since I want my program to create one campaign at a time. I think I'm going to need Singleton pattern.
Each campaign has attributes that are common and attributes that are specific. E.g. Adhoc campaign does not need a time schedule. Also a scheduled campaign reads from a pre-written SQL file while ad hoc campaigns are run instantly.
I would like to have a well-structured design to support these. Is a combination of Factory and Singleton the answer?
If so, can I have a simplified example?
If not, what do you recommend?
Patterns are nice, but a pattern is a solution to a specific problem. You don't seem to have any of those specific problems.
From your requirements, you need a single variable of a base-type and an if-statement to put either one or another derived class into it.
If you want noodles, you have to decide if it should be spaghetti or tortellini. Pick one, heat, eat. Please don't build a NoodleHeatingAbstractFactory that only allows heating of a single, well guarded noodle dish. Keep it simple.
You typical use singletons when you want a global shared resource. To have one instance of something you don't necessarily need a singleton unless it is created from multiple locations, if not you can just create one instance and pass it around. I think AbstractFactory fits well here, but not sure about Singleton.
Update
If the user chooses which campaign to create I don't think you need a factory. Just create the appropriate campaign and you can store it in a ServiceLocator which is usually a Singleton or alternatively inject it into each Form/Window that you create.
The dependency injection Tends to be a it easier to unit test as you can mock the campaign
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have never used a ioc-Container but from what I have read, the objects suffixed with "Container" seem to me a factory that reads from configuration/context, does its magic and returns an object of concrete type according to the read configuration/context.
What key aspects am I missing?
Using containers seems to add complexity (which is time consuming for development, refactoring and configuration), where to use and which are the key benefits?
Both IoC containers and factories build other objects, but that's where the similarities end.
A factory is an object which knows how to build other objects. It encapsulates extra logic, perhaps configuration time information etc. It can build several of a related type of objects, such as from a hierarchy of objects. But the number of objects it can build is part of the structure of the factory. So you might have a SqlConnectionFactory or a RequestHandlerFactory, which know what sort of SqlConnections or RequestHandlers to build, but if you want to build InputValidators you're going to need to make a new factory.
An IoC container is a tool used to help with the inversion of control pattern. But it's not strictly needed. IoC makes you be explicit in what dependencies your objects have, and makes you provide those dependencies when the object is created/initialized. When done right, this helps with separation of concerns, decoupling between components, unit testing etc. and generally makes the resulting code "better". But because manually wiring up object graphs is a hassle, a number of frameworks for doing this automatically, either from external configuration or from code annotations have appeared. These are called IoC containers. The way they initialize objects is much more generic than a factory. You can ask it to build any type of object, and as long as it knows something about those objects (the signature of the constructor, in the simplest case), it can build them.
It's more usual to see an IoC container use a factory, than the other way around. In much of the code I've seen, the need for factories for all but the most complex objects is greatly alleviated though.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm trying to be a better C# programmer and use best-practice design patterns.
Can someone please explain how best to approach the following real-world example in code, using the repository pattern and the observer pattern?
I have a system which contains companies. Companies have departments and employees. Also, each company pays a subscription which limits the number of departments / employees they can create. You can't have a company without at least one department and that department should have one employee.
When I create a repository for companies - in the "create company" code, should I also create the first department and the first employee, or should I leave the repositories separate, or is it better to have a simple single call for "Create company" that does it all?
In the "Create department" code - I want to ensure the company can't create more departments that they have paid for. I'm guessing the right thing here is the observer pattern - notify the "Subscription" code that the company is attempting to create a new department and then stop it if it's going to go over the limit - but I haven't got a clue where to start!
All help very much appreciated.
You are trying to implement business validations by using the observer pattern. That is the wrong approach IMHO.
Since the observer pattern is about objects being notified of certain events, and those objects are implementing certain behaviour, it is not a match for business objects containing data which are being persisted by the repository pattern.
What you are describing is simple validation of business objects. You are trying to make sure that your data is only being persisted when certain checks are passed. In your repository (or somewhere in your domain/business layer if you have one) take your data, validate it, and persist it.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I know that there are many IoC frameworks in .net ( They are: Ninject, Unity, Castle Windsor , Structure Map ) They also used to same goal - resolving dependencies. But i don't understand in which cases should be used certain framework! they are almost similar. Who can simply explain the main differences?
It depends on your needs. Some containers are very mature or have a big community. Others are feature rich or very fast. It all depends on what you need, but the problem is that you only know this when you already did one or two projects using DI and DI containers. And still, when you're architecture changes the requirements for your container will change.
So whatever container you pick, be prepared to change your container. This means, stick to the Dependency Injection pattern and prevent yourself from letting application code have a direct dependency on the container (a pattern which is called Service Locator).
Each and every one has a fatal flaw.
On a more serious note they surely do essentially the same thing, but differ in implementation details, conventions, performance, auxiliary features and suggested usecases.
I don't think that you should really sweat picking the IoC container. Stick to one you're used to and continue with your core functionality.
DI/IOC or whatever you want to call it is a means to an end - not the end in itself. Find one you like and that does everything you need and go with it (until you're told to use something else).
I rolled my own based on StructureMap and probably learned more doing that than actually using any of the others.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
Can someone please explain to me the Repository Pattern in .NET, step by step giving a very simple example or demo.
I know this is a very common question but so far I haven't found a satisfactory answer.
As a summary, I would describe the wider impact of the repository pattern. It allows all of your code to use objects without having to know how the objects are persisted. All of the knowledge of persistence, including mapping from tables to objects, is safely contained in the repository.
Very often, you will find SQL queries scattered in the codebase and when you come to add a column to a table you have to search code files to try and find usages of a table. The impact of the change is far-reaching.
With the repository pattern, you would only need to change one object and one repository. The impact is very small.
Perhaps it would help to think about why you would use the repository pattern. Here are some reasons:
You have a single place to make changes to your data access
You have a single place responsible for a set of tables (usually)
It is easy to replace a repository with a fake implementation for testing - so you don't need to have a database available to your unit tests
There are other benefits too, for example, if you were using MySQL and wanted to switch to SQL Server - but I have never actually seen this in practice!
This is a nice example: The Repository Pattern Example in C#
Basically, repository hides the details of how exactly the data is being fetched/persisted from/to the database. Under the covers:
for reading, it creates the query satisfying the supplied criteria and returns the result set
for writing, it issues the commands necessary to make the underlying persistence engine (e.g. an SQL database) save the data
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
My class has like 30-40 properties, and I really want to unit test.
But I have to create a moq instance (many of them, with different combinations etc).
Is there an easy way? This is real work!
My class can't be refactored, "trust me" (hehe, no really it can't, they are just properties of the object that are very tightly coupled).
Sounds like you need to do some major refactoring. I would start by taking a good look at the single responsibility principle, and making classes that will only have 1 reason to change. Once you break out functionality into separate classes that deal with only 1 responsibility, you can start writing tests for those classes, and they shouldn't take a page-full of mock objects.
This is the advantage of test-driven development -- you immediately run into the problems caused by huge classes, and are driven to avoid them if you want to be able to write tests.
Personally, I don't think you need to try every combination to test your class.
You mention lots about properties, but little about behavior. Shouldn't the tests be about behavior more than state?
There could well be situations where, due to the nature of the class, there are a lot of legitimate properties. I know, I've been there and done that. When examining that class, it is important to determine that each property really does belong in the one class, and not elsewhere. Single Responsibility Principle comes in play here.
Unfortunately, to break any tight coupling, it will take some time and effort to refactor. Just suck it up and get 'er done!