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.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am working in my very first MVC Project which consist in a online quiz web application. I am currently doing my documentation and I am trying to figure out how my class diagram will look like. There are three types of users Admin, teachers and students.
So far I have reach the conclusion that I need this as a part of my Model:
*UsersDAO
*QuestionsDAO
*Quiz Model
*Quiz Queries
For the controllers I may need a LoginController and QuizController maybe a UserController
I am not sure if I should have a "View" for every "Controller", or if I need a "Controller" for every type of user. The examples that I have found in the internet are very simplistic because they only contain one Action.
Please any suggestions?
The whole point of UML is to design the system in abstract. Things like controllers and views are implementation details that can vary depending on what system you end up building this in. All you should be modeling is your business objects and the relationships between them, not things like how they will be persisted or how those relationships are managed.
Something like a view or controller is not a universal concept. Not every framework has a concept of those things, and as a result, a model that includes those is by definition not "universal". FWIW, I'd also throw shade on modeling things like DAOs, DTOs, View Models, and the like. Those, too, are implementation details, and highly dependent on things like frameworks, data stores, etc.
Your model includes below operations (without login system):
Teacher (CRUD), design exam questions, and score answers
Student (CRUD), take quiz, and get quiz scores
Quiz (CRUD)
So you can implement this model by three Controller:
TeacherController
StudentController
QuizController
For CRUD operations you can use a View but for other operations you should add new View.
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
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 9 years ago.
Improve this question
I am working in MVC from last one year. I am following the MVC approach i.e simple appraoch and not Repository patterns. Now, I come to know about the advantages of using Repository with dependency injection and I feel it follows the oops in right way.
That is my thinking.
In one of my sample/test project I started working with repositor and have few questions about it:::
1) when we use EDMX , suppose I have a table names "Users", it automattically
creates a class named as "users" which contains all the fields as properties.
What I usually follow is I create a model layer and add a class in that model layer of name
"myUsers" that will contains same properties as the class users have.Now, I will bind the view
page with "myUsers" so that it cannot deal directly with DAL.
and Whenever I post something from my view page , the object comes in "MyUsers" model,
and here I again do something like this.
Users=MyUsers(I do this by doing this for each property like::
Users.Name=MyUsers.Name
and then I save it in Database.
I use above approach and in my applications I have used the above approach.
Now my question is
Can I bind my view page directly with "Users" class? As I see some applications,
it is happening. It reduced much work and also overheads in application.
What is correct approach ? to deal directly with DAL or there should be models
in between them?
"Correct approach" is subjective. We like to create ViewModels that exist purely to show domain objects in a view because it means we can separate view logic from the domain. We may not always want to show / load every property of a domain object. As another example, we put DataAnnotations attributes for validation on our ViewModels.. but we leave the domain objects as nice little POCO's.
Manually mapping them like you are is an incredible waste of time though. There are frameworks that do that for you.. such as:
Automapper
ValueInjector
According to me, this is the correct architecture.
Let me explain the answer in comments below.
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 9 years ago.
Improve this question
I have been developing web apps using .net and c# from last 1 year, but there is some confusion going on in my mind regarding OOP principals implementation.
1) What i learned from the object oriented books was that every class should have its specific methods, but when i came across the code of a senior developer, i saw that the developer has created a separate business layer with a business layer class containing all the methods of all the classes.
Is this approach of using separate business class containing all the methods being used in our app is justified by any design pattern or by any other resource, or it is just an awful design?
Please elaborate your answer in detail as this can also helps other newbies out there...
Architecture is an art not a science. There are good architectures and bad architectures, but there is not a single correct architecture.
For example your Senior developer may have created a Facade (design pattern) on top of your more complicated data access layer to simplify data access. For instance you could have a dozen entities for ordering a product, and you would like to create a facade for everything you need to do while ordering a product.
Just look at the architecture and try to analyze yourself if you think it could be better. The more architecture you know the better your judgment will be, but architecture is rarely black and white.
Also, just because someone is senior it doesn't necessarily mean that they know what they are doing or that they don't make mistakes.
Also, Inheritance can be done in EF:
Inheritance in EF
there is no single architecture one can follow, for example when building strictly SOA systems it is VERY common to have model classes that are only data, no methods whatsoever. Whereas all the business logic classes exist in a different namespace. Furthermore when you send your domain classes over the wire you will typically create dedicated classes for that purpose in a different assembly dedicated to the SOA.
The architecture I describe above is directly from the Microsoft Architecture Guidance package for VS.
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