Gday guys.
Clearly im an amateur at programming, but am learning!
I want to create a simple asp .net web site that basically is a very small database for repair jobs that we have going on in our office.
I am uncertain of a few things:
Firstly, how do I structure my classes?
I know I will have a job class that will have properties such as name, issue description, technician etc and also have methods for loading certain jobs into that instance. But if I have a page that will search for all jobs, where abouts would that method that returns ALL jobs lie? I can't really see it going into the Jobs class, as the Jobs class really only deals with a single instance of a Job, and not multiple jobs. Do I have to have a separate class called Jobs that has the methods for getting ALL jobs?
Second question- if I have methods that retrieve data from a database, what is the best type to return this to the calling class? A List? A DataSet?
Finally, should I again have a separate class for the data access and a separate class for the business logic type stuff for Job?
I know I might be looking into such a simple application too much here, but I want to get myself into the habits of using the RIGHT techniques from the start..!
Looking forward to haering your advice!
Visual Studio provides sample projects, that you can create by using the New Project option... It can create a fully working web application, so that you can start learning from it.
You can try MVC. Create a new MVC project and it will ask if you want it to be empty, or if you want to create a sample project with working code... of course you should take the second choice... after that you can run the application and see what happens! =)
Then you can start exploration... try changing things in this project. And question about everything you don't understand. StackOverflow is a good place, as you may have noticed.
1) Refactoring by Martin Fowler realy helped me grasp OO programming. It can teach you not only to refactor your classes, but what to look for when designing them.
In your example, the method that returns all jobs will go in to the class that holds the list of jobs. Stay away from creating a List<Job>, create a single instance of a class that holds a List<Job>.
2) Stay away from DataSets unless you know exactly why you need to use one. I suggest you use WCF + Linq to fetch data from your database as a list of your own class.
3) WCF + Linq will take care of your data access layer. Your own classes will be your busness logic layer. Finaly you will benefit from an addition View layer for your interface.
You need to separate repository class from entity class - make class have a single responsibility. That's basic OO principle.
list would be better and simple.
of course, you need to separate DAL and BL.
If you want right way to build a web site, be interested in MVC, TDD, Linq, ORM (e.g., EF), Dependency Injection, and other design patterns.
Related
I am building an application using DDD principles. I am now thinking about the namespace structure in the core of my application. Please see the idea below:
Company.Application.Core.Entities
Company.Application.Core.ValueObjects
However, I cannot find a single example of an application on GitHb, which follows this convention. Is there a specific reason not to follow this naming convention?
I also have a base class for entities i.e. Company.Application.Core.Entities.Entity and a base class for value objects i.e. Company.Application.Core.ValueObjects.ValueObject
The alternative option is to put all Value Objects and Entities in: Company.Application.Core
Your approach will work, but such composition tells story about your code focused on DDD Building Blocks, not about immanent features of your domain. In DDD we want to show important things about domain, the technology issues are not the most important concerns anymore.
I suggest creating following namespaces:
YourCompany.YourApplicationName.YourParticularBoundedContextName.Application
here you can keep all Application Scope building blocks i.e. Application Services and DTO's which are used to transfer parameters to Application Services and return data from them.
YourCompany.YourApplicationName.YourParticularBoundedContextName.Domain
this is the namespace where you will create subnamespaces for Domain Scope building blocks.
YourCompany.YourApplicationName.YourParticularBoundedContextName.Domain.AggregateName
each Aggregate have its own namespace in which there are Aggregate Root class, Entities and VOs used internally in this Aggregate, Repository interface, Aggregate Factory if needed etc.
I don't know if in C# it is possible, but in Java there is another advantage of having separate package (namespace) for Aggregate - you can make Aggregate Root class public and all other Entities and VOs that are internally used as package scope, so they will not be visible outside package (namespace). This way you build public API for your Aggregate that no one can break, because there is a guardian: the compiler :)
YourCompany.YourApplicationName.YourParticularBoundedContextName.Infrastructure
here is a place for repositories' implementations (each in subnamespace of corresponding Aggregate)
Base classes can be kept in:
YourCompany.YourApplicationName.Domain
and even kept in separate project as you can try to reuse it in another application.
What is the advantage? When working with code you are focusing on features and domain rather than on technological aspects. You will more frequently have to cope with problems like "how does this process flow look like" than "I want to see all my Entities and VOs at once", so let your code structure support this. Separating Entities (Aggregates parts actually) and VOs (also Aggregate parts) into separate namespaces you lost information what is working with what. You can simple end with big ball of mud, because you will reuse something that shouldn't be reused.
Please look at:
https://github.com/BottegaIT/ddd-leaven-v2
it is a sample project in Java with packaging done this way. Maybe it will help you.
Another example is:
https://github.com/VaughnVernon/IDDD_Samples
which is a sample for Vaughn Vernon's book about DDD.
There is also article that can be useful:
http://www.codingthearchitecture.com/2015/03/08/package_by_component_and_architecturally_aligned_testing.html
Using separate namespaces for your Entity types (that map to database tables etc.) and your DTO types (used for passing data between client and server layers of your application) is pretty standard practice, even if .Entities and .ValueObjects aren't particularly common choices. I don't think it's worth worrying about too much as long as you use them consistently.
This might be a long list of questions but please bear with me. I started building LOB applications with WPF, PRISM, CODE FIRST and SQL CE, and after my first application (or attempt) I have many questions, so to begin with:
Where should business logic go, in the model or in a BLL layer just above the domain layer ?
Should view models receive references to repositories or should repositories be used only by the domain model objects ?
To put the second question in another way, what sort of objects should be given to view models ?
I use the same view model in display (in a data grid for example) and for editing in a form but that causes a lot of trouble, is there a better way to do this without code duplication ?
The biggest problem I have faced was that I always organized my view models in hierarchical relationships without allowing the children in the hierarchy to obtain references to their parents, and since the views bound to those children and invoked methods that caused the addition of objects to the repositories I couldn't find a way to notify the parents of the changes to the those repos. so the bound views could be updated, I have seen some people solve this using events but I don't like this solution and I would like to know if there is a better way to do it ?
Can anyone point to an example of building real life LOB applications using the technologies mentioned above, at least not examples that use VB .NET or WCF (I want local databases).
I'm developing a LOB app right now, with WPF, Entity Framework Code First and SQL CE 4.0 with a local database. I'm not using PRISM, but I'm using MEF as IoC with my own implementation.
So far, I recommend that you use the benefits of Code-First approach and implement as much business logic in your domain classes as possible. Also implement INPC in them. If you don't you'll end up having all your properties duplicated in your ViewModels, which is nonsense. There is no rule that says that the model should be dumb (although some people tend to think so), but a dumb model just makes the ViewModels more tedious to work with.
No clear recommendation here without knowing more of your project, but common sense: try to stick to best practices unless they start coming in your way. "Perfect" is often the enemy of "good".
Let the ViewModel get whatever they need (single model objects, collections, etc.) to serve your views. Often the simpler solution is easier to maintain in the long term.
I don't quite understand what you mean with this... I use my ViewModels several times if possible, but think that a ViewModel's function is to serve a View, if you are having trouble trying to get one VM to work for several Views, it's probable that you need to divide it into two different VM. Just gather all the common properties and methods in a base class and inherit from it as you need.
There are some loose-coupled ways for the VMs to communicate with each other. I'm using MVVM Light Messenger class for such things, but I understand that PRISM provides a similar functionality. It's not a sin to reference the parent from the child if you don't abuse it. I have a ViewModelBase<T> and the child have a reference for their parent pointing to the base class and specifying the T type, a good balance between hard and loose reference so far.
If someone points you to such an example, let me know! Actually, working with a local database should be simpler. In my case I'm using a singleton context (which a lot of people seem to loathe) but since this is a local app, with a single user and no threading complications a singleton context makes my life much easier. I'm still waiting to find a real good reason not to do so with this conditions.
PS: some people will probably downvote your question because... it is not ONE question, and it opens room for a lot of debate. If it gets closed, try the chat.
Hope this helps you, regards!
I'm currently designing the foundation for a large application. We are going with the traditional 3 tier system using EF in the data layer, plain jane c# classes in the business layer and MVC / WCF for the ui layer. We have prototyped enough of the application to realize that this will work for us, however due to the complexity of the business requirements it will be common for some of the business components interact with one another.
Consider the following two business components:
RetailManager - Deal with everything related to retail in the system
CartManager - Deals with everything related to the shopping cart experience
The two interact, for instance, during the checkout process when an item is purchased. The inventory for the purchased item needs to be reduced.
Here is my thought process so far:
Let business components reference each other and ensure cyclical references never happen (CartManager references RetailManager, but never the other way). "Checkout" would be a method on the CartManager class, and it would call a method on the RetailManager to adjust inventory. While this will work, I'm not sure how well it will scale, and what the maintenance cost will be over time. It doesn't feel 100% "right" to me.
Create a Facade between the business components and the UI tier. In this example, the Facade would have the checkout method and a reference to both managers. I like this approach more than the first, however I know that not all of my business objects will need a Facade, and I don't want to create a ton of Facade classes just to have empty pass through methods.
I'm leaning towards 2, with the caveat that I will only create facade classes where needed. The UI tier will have access to both the Facade and the business layer components and will have to know when to use which (the only part I don't like about this solution).
I've done a lot of research but haven't been able to come to come up with a solution that feels completely right.
Any thoughts on using the facade pattern in this way, or other ideas to solve the problem are welcome.
Thanks in advance.
That's a typical problem for using manager/service classes. they always tend to get bloated. When you come to that point it's probably better to start using commands instead.
The great thing since you are using an IoC is that you doesn't have to refactor all the code directly, but can do it when there is time. Simply start writing commands for all new features while keeping the old architecture for everything else.
Here is a intro to commands: http://blog.gauffin.org/2012/10/writing-decoupled-and-scalable-applications-2/
And an intro to my own framework: http://blog.gauffin.org/2012/10/introducing-griffin-decoupled/
I would tend to go with facade implementation.
I would first ask myself, whose responsibility is it to make sure that inventory is reduced when a checkout happens? I don't think it is responsibility of CartManager to reduce the inventory. I would have a third class (in your case facade) that makes sure that whenever an item is checked out by CartManager, corresponding item is reduced from inventory.
Another option I would consider is event based implementation. CartManager would raise a ItemCheckedOut event whenever an item is checked out. RetailManager would subscribe to this event and would reduce the inventory whenever an event is raised. If you are new to event driven design, follow this question on quora - http://www.quora.com/What-are-some-good-resources-on-event-driven-software-design
I personally like the pattern of CQRS, it fits naturally with other architerural patterns
such as Event Sourcing and suited to complex domains.
I need to design a Data access layer DAL .Net Enterprise library version 3.5 Data access application block (DAAB)
In my application,I've various logical modules like Registration, billing, order management, user management,etc
Am using C# business entities to map the module objects to database tables and then return the List collection to the client.
I would like to design my DAL in such a way that if tomorrow we decide to use some other data access framework we should have minimal code change.
Given this, how do i design my class structure?
I thought I would have a class DbManagerBase which would be a wrapper over existing .net DAAB
This class DbManagerBase would implement an interface called IDbManagerBase which would have public methods like ExecuteReader, ExecuteNonQuery, etc.
The client class ie. RegistrationDAL,UserManagermentDAL would have the following code inside each of its methods:
IDbManagerBase obj= new DbManagerBase()
obj.ExecuteReader(myStoredProcName)
.
.
.
is this a good OOPS design?may i know any better approach please?or do i need to use inheritance here?
Can i have all the methods in DbManagerBase class and RegistrationDAL,UserManagermentDAL classes as static?I guess,if i've methods as static then the above interface code wont make any sense...right???
To truly abstract the DAL I'd use the repository pattern.
To answer a few of the questions:
Can i have all the methods in
DbManagerBase class and
RegistrationDAL,UserManagermentDAL
classes as static?
I would probably go with a non-static approach cause it gives the flexibility to better control instantiation of the DALs (eg. you could create instances of them from a factory), also it will allow you to have two DALs in place that are talking to different DBs in a cleaner way. Also you will not need to create an instance of the DbManagerBase in every object since it would be an instance member.
Regarding IDbManagerBase having ExecuteReader, ExecuteNonQuery and obj.ExecuteReader(myStoredProcName)
I would be careful about baking the knowledge about database specific concepts in too many places. Keep in mind some DBs to not support stored procedures.
Another point is that before I went about implementing a DAL of sorts I would be sure to read through some code in other open source DALs like NHibernate or Subsonic. It is completely possible they would solve your business problem and reduce your dev time significantly.
If you are looking for a small example of a layered DAL architecture there is my little project on github (it is very basic but shows how you can build interfaces to support a lot of esoteric databases)
i have the following directories:
-UI
-BusinessLogic
-DataAccess
-BusinessObjects
if i have a class that is a client stub to a server side service that changes state on a server system, where would that go . .
this code belongs in the recycle bin ;-)
seriously, if you wrote it and don't know where it goes, then either the code is questionable or your partitioning is questionable; how are we supposed to have more information about your system than you have?
now if you just want some uninformed opinions, those we've got by the petabyte:
it goes in the UI because you said it's a client stub
it goes in the business logic because it implements the effect of a business rule
it goes in the data access layer because it is accessing a state-changing service
it goes in the business object layer because it results in a state change on the server
it would be more helpful if you told us what the stub actually does; without specifics it is hard to know where it belongs, and/or it is easy to argue in a vacuum about where it "should" belong
I would consider this a form of data access, although it's not clear to me that you need to put it in the same project as the rest of your data access classes. Remember that the layers are mainly conceptual -- to help you keep your design clean. Separating them into different projects helps organizationally, but is not mandatory. If it's an actual stub class, then the data access project is probably the natural home for it, but if it's only used in the UI layer, then keeping it there would probably be ok.
I don't think it belongs in any of those. You either need a new directory or a new project entirely. But out of those given, I would have to say BusinessObjects because it's certainly not accessing data according to your description, and rather is simply acting like a local object (stub).
In a web service repository.